Skip to content

fix(fmlint): honour enable="False" in B006 and read Set Error Capture state correctly - #92

Open
anwespanda wants to merge 1 commit into
petrowsky:mainfrom
anwespanda:fix/fmlint-disabled-steps-error-capture-state
Open

anwespanda wants to merge 1 commit into
petrowsky:mainfrom
anwespanda:fix/fmlint-disabled-steps-error-capture-state

Conversation

@anwespanda

Copy link
Copy Markdown

Two defects in agent/fmlint/rules/best_practices.py, both producing false positives. They surfaced together while linting a generated script, but they're independent.

1. B006 counted disabled steps

The step loop never inspected the enable attribute, so a step with enable="False" — which FileMaker never executes — was treated as live.

Insert Text is in _RECORD_MODIFYING_STEPS, and CODING_CONVENTIONS.md prescribes a disabled Insert Text targeting $README as the standard doc-block pattern:

<Step enable="False" id="61" name="Insert Text">
  <SelectAll state="False"/>
  <Text>PARAMETERS: ...</Text>
  <Field>$README</Field>
</Step>

So every script written to the project's own documented convention triggered a spurious B006, warning about record locks for a step that cannot acquire one. Minimal reproduction — this alone was enough:

<Step enable="True" id="86" name="Set Error Capture"><Set state="True"/></Step>
<Step enable="False" id="61" name="Insert Text">...<Field>$README</Field></Step>
WARN [B006] Set Error Capture [On] is enabled and record-modifying steps are
     present (e.g. Set Field) but no Get(LastError) check was found.

There is no Set Field in that script. Removing the disabled step made the warning disappear. A warning that fires on the documented house style is one people learn to ignore, which is how a genuine B006 gets missed.

2. B001 and B006 read the state from the wrong element

Both rules did:

state_el = step.find("State")

In fmxmlsnippet the state is carried by <Set state="True|False"/> — per step-catalog-en.json ("xmlElement": "Set", "xmlAttr": "state") and snippet_examples/steps/control/Set Error Capture.xml. find("State") always returns None, so the [Off] branch was unreachable and Set Error Capture [ Off ] was treated as On, inverting the precondition of both rules:

<Step enable="True" id="86" name="Set Error Capture"><Set state="False"/></Step>
<Step enable="True" id="76" name="Set Field">...</Step>
WARN [B006] Set Error Capture [On] is enabled ...

Fix

Skip disabled steps in B006, and look for <Set> first while retaining the <State> lookup as a fallback in case any older fixture relies on it.

Verification

Behaviour matrix — B006 now fires only on the true positive:

Scenario Before After
capture On + Set Field, no error check fires fires ✅
capture On + Set Field + Get(LastError) silent silent ✅
capture Off + Set Field fires ❌ silent ✅
capture On + disabled Set Field fires ❌ silent ✅
disabled capture + Set Field fires ❌ silent ✅

The true-positive diagnostic still reports the same line number. I didn't add tests — I couldn't find a suite for agent/fmlint/ to extend. Glad to add one if you point me at the right place.

🤖 Generated with Claude Code

… state correctly

Two defects in agent/fmlint/rules/best_practices.py, both causing
false positives.

1. B006 (record-lock-unchecked) counted disabled steps

The step loop never inspected the `enable` attribute, so a step with
enable="False" — which FileMaker never executes — was treated as
live. Insert Text is in _RECORD_MODIFYING_STEPS, and
CODING_CONVENTIONS.md prescribes a *disabled* Insert Text targeting
$README as the standard doc-block pattern. Every script written to
the project's own documented convention therefore triggered a
spurious B006, warning about record locks for a step that cannot
acquire one. Habitually ignoring that warning is how a real B006
gets missed.

2. B001 and B006 read the Set Error Capture state from the wrong element

Both rules did:

    state_el = step.find("State")

In fmxmlsnippet the state is carried by <Set state="True|False"/>,
per step-catalog-en.json ("xmlElement": "Set", "xmlAttr": "state")
and snippet_examples/steps/control/Set Error Capture.xml. find("State")
always returned None, so the [Off] branch was unreachable and
`Set Error Capture [ Off ]` was treated as On — inverting the
precondition of both rules.

Skip disabled steps in B006, and look for <Set> first while retaining
the <State> lookup as a fallback.

Verified with a behaviour matrix. B006 now fires only on the true
positive:

  capture On + Set Field, no error check   -> fires   (unchanged)
  capture On + Set Field + Get(LastError)  -> silent  (unchanged)
  capture Off + Set Field                  -> silent  (was firing)
  capture On + disabled Set Field          -> silent  (was firing)
  disabled capture + Set Field             -> silent  (was firing)

The true-positive diagnostic still reports the same line number.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant