Repository navigation
fix(fmlint): honour enable="False" in B006 and read Set Error Capture state correctly - #92
Open
anwespanda wants to merge 1 commit into
Conversation
… 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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
enableattribute, so a step withenable="False"— which FileMaker never executes — was treated as live.Insert Textis in_RECORD_MODIFYING_STEPS, andCODING_CONVENTIONS.mdprescribes a disabledInsert Texttargeting$READMEas the standard doc-block pattern: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:
There is no
Set Fieldin 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:
In fmxmlsnippet the state is carried by
<Set state="True|False"/>— perstep-catalog-en.json("xmlElement": "Set","xmlAttr": "state") andsnippet_examples/steps/control/Set Error Capture.xml.find("State")always returnsNone, so the[Off]branch was unreachable andSet Error Capture [ Off ]was treated as On, inverting the precondition of both rules: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:
Set Field, no error checkSet Field+Get(LastError)Set FieldSet FieldSet FieldThe 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