[BUG][flow-engine] HardcodedId never reports a 15-character record ID, and reports words of 16, 17, or more than 18 characters

從 packages/code-analyzer-flow-engine/FlowScanner/queries/optional_query.py 開始，尤其檢查 is_valid_salesforce_id，並查看 Flow 的 HardcodedId 規則如何使用它。針對列出的 15 字元 ID、有效和無效的 18 字元 ID，以及單字範例新增聚焦測試；issue 指出，現有的引擎測試沒有涵蓋此函式。完成標準是有效 ID 會被回報，而單字和校驗和錯誤的 ID 不會被回報。

Have you tried to resolve this issue yourself first?

• I confirm I have gone through the above steps and still have an issue to report.

Bug Description

The Flow rule HardcodedId misses every 15-character Salesforce record ID, and it reports text that is not an ID.

id_pattern = re.compile(r"^(?=.*[0-9][0-9])[a-zA-Z0-9]+[a-zA-Z0-9]{15}(?:[0-5][A-Z0-5]{3})?$")

[a-zA-Z0-9]+ needs at least one character, and [a-zA-Z0-9]{15} needs 15 more, so the pattern needs 16 characters or more:

A 15-char ID never matches.
Words of 16 or 17 characters, or of more than 18, match when they contain two digits together. is_valid_salesforce_id checks the checksum only for a length of exactly 18 (L1136-L1146), and returns true for every other length that the pattern accepts. So Region2026Totals, Invoice2026Number, and Quarter2026SummaryReport are reported as hardcoded IDs.
An 18-character ID with no two digits together is missed, because of the lookahead (?=.*[0-9][0-9]). (This is rare, I'm sure.)
The optional group (?:[0-5][A-Z0-5]{3})? never takes part in a match of an 18-character ID, because [a-zA-Z0-9]+ takes the extra three characters first. It also asks for four characters, where the suffix of an 18-character ID has three.

Output / Logs

(I had Claude run some tests. It didn't like 2026 and preferred 2024, for some reason.

Code Analyzer 5.16.0 on 23 Flow files, one case in each. Every file also holds the same 18-character ID with a correct checksum, 0015g00000Ctr01AAB, as a control on line 13. The engine reported the control in all 23 files, so every file was scanned. The other results:

Value of the stringValue	Length	Reported
0012800000AbCdE	15	no
00Q5g00000Xyz12	15	no
0125g000000AbCd (a record type ID)	15	no
0012800000AbCdEAAV (correct checksum)	18	yes
0012800000AbCdEZZZ (wrong checksum)	18	no
a0B5g0X1Y2Z3W4VEKV (correct checksum, no two digits together)	18	no
Region2024Total	15	no
Region2024Totals	16	yes
Invoice2024Number	17	yes
QuarterlyTotal2024	18	no
Quarter2024SummaryReport	24	yes
The run found 27 violations: the 23 controls, the correct 18-character ID, and the three words.

Steps To Reproduce

The short way. Call the installed function on four strings (the path is that of a default Salesforce CLI installation on macOS or Linux; any Python 3.10 or later):

python3 -c "import sys; sys.path.insert(0, sys.argv[1]); from queries.optional_query import is_valid_salesforce_id as f; [print(s, len(s), f(s)) for s in ['0012800000AbCdE', '00Q5g00000Xyz12', 'Region2024Totals', 'Invoice2024Number']]" ~/.local/share/sf/node_modules/@salesforce/plugin-code-analyzer/node_modules/@salesforce/code-analyzer-flow-engine/FlowScanner

It prints False for the two 15-character IDs and True for the two words.

Through the CLI.

Make a folder flows with an autolaunched Flow that has one Assignment, which sets a Text variable to the stringValue 0012800000AbCdE, and a second Assignment with the stringValue Region2024Totals.
Run sf code-analyzer run --workspace flows --rule-selector flow:HardcodedId --view table.
The rule reports the second Assignment and not the first.

Expected Behavior

The rule reports a 15-character ID and an 18-character ID with a correct checksum, and does not report a word that is not an ID. In the table above: the three 15-character IDs and the two 18-character IDs with a correct checksum are reported, and the three words are not.

Operating System

macOS 27.0.1 (arm64)

Salesforce CLI Version

@salesforce/cli/2.155.7 darwin-arm64 node-v24.21.0

Code Analyzer Plugin (code-analyzer) Version

code-analyzer 5.16.0

Node Version

v24.18.0

Java Version

openjdk version "21.0.11" 2026-04-21 LTS

Python Version

Python 3.14.6

Additional Context (Screenshots, Files, etc)

A fix. Every Salesforce record ID has 15 characters: a 3-character key prefix, 2 characters for the instance, a reserved character that is 0, and 9 characters for the record. The 18-character form adds a 3-character checksum, each character from A to Z or 0 to 5. A pattern that follows that layout:

-id_pattern = re.compile(r"^(?=.*[0-9][0-9])[a-zA-Z0-9]+[a-zA-Z0-9]{15}(?:[0-5][A-Z0-5]{3})?$")
+id_pattern = re.compile(r"^[a-zA-Z0-9]{5}0[a-zA-Z0-9]{9}(?:[A-Z0-5]{3})?$")

is_valid_salesforce_id needs no change: with this pattern it accepts only lengths 15 and 18, and for 18 it still compares the string with to18 of its first 15 characters.

Tested on the 23 cases above and the control, with the installed to18. With the fix, all five 15-character IDs and all four 18-character IDs with a correct checksum match, including a0B5g0X1Y2Z3W4VEKV; the wrong checksum does not match; and none of the seven words matches. In the engine's tests, HardcodedId appears only as a description in test/test-data/goldfiles/all_rules.goldfile.json, and is_valid_salesforce_id not at all, so these cases could be the first tests of the rule.

Not part of this fault, but worth knowing: the rule reads a stringValue only when its whole text is the ID. It does not find an ID inside a formula, a text template, or a URL, such as /lightning/r/Account/0012800000AbCdE/view.

Workaround

Switch the rule off in code-analyzer.yml, and find IDs with a custom PMD rule for Flow XML.

Urgency

Low