barrierModel arity mismatch: "Expected 4, but was 3" on documented-correct 3-column rows (python-all, javascript-all)

Commencez par reproduire l’échec de .github/codeql/extensions/.../models/log-injection.yml avec les bundles de CLI 2.26.4 et 2.27.0. Lisez ApiGraphModelsExtensions.qll et comparez sa signature barrierModel avec la forme documentée à trois colonnes et les packs python-all/javascript-all. Le travail est terminé lorsque vous avez confirmé l’arité valide exposée à l’utilisateur et déterminé si la correction doit être apportée aux packs, à la validation de CLI ou à la documentation.

Summary

CodeQL fatally errors when resolving barrierModel data extensions for codeql/python-all and codeql/javascript-all, on rows that exactly match the documented, correct format (and the format used identically by sourceModel/sinkModel, per github/codeql#21004).

Repro

.github/codeql/extensions/.../models/log-injection.yml:

extensions:
  - addsTo:
      pack: codeql/python-all
      extensible: barrierModel
    data:
      - ["sciemo_one_client_base.safe_log", "Member[safe_log_value].ReturnValue", "log-injection"]

This is the exact format shown in the official docs (https://codeql.github.com/docs/codeql-language-guides/customizing-library-models-for-python/, "Example: Taint barrier using the 'escape' function") and matches barrierModel(type, path, kind) as formally declared in the Ruby docs' reference section.

Error

A fatal error occurred: A tuple in a data extension for the extensible predicate 'barrierModel' has an incorrect number of columns. Expected 4, but was 3.

What we tried

Assuming a genuine 4-column requirement (the trailing column being QlBuiltins::ExtensionId, per ApiGraphModelsExtensions.qll), we tried supplying a literal 4th value ourselves. None satisfy validation — all fail with:

ERROR: In extension for codeql/python-all:barrierModel, row 1 is invalid. Found '"...", "...", "log-injection", <value>', which does not match the signature 'barrierModel(string type, string path, string kind, [int origin])'.

Tried for <value>:

• "manual" (string, matching the provenance convention used elsewhere in MaD, e.g. sourceModel/sinkModel)
• 0 (int, repeated across rows)
• unique sequential ints per row (1000, 1001, 1002)

All fail identically. Per github/codeql#21004, barrierModel's trailing param is QlBuiltins::ExtensionId madId, described as "the data extension row number" — auto-populated internally, never meant to be user-supplied (same as sinkModel/sourceModel, which only ever take 3 user columns). So there appears to be no valid literal a user can write to satisfy the 4-column requirement the arity check enforces.

Versions tried (same failure on both)

• CLI 2.27.0 (codeql-bundle-v2.27.0, python-all 7.2.5 / javascript-all 2.10.1, via floating codeql-action@v4)
• CLI 2.26.4 (codeql-bundle-v2.26.4, javascript-all/javascript-queries 2.4.4, via tools: pinned explicitly to the 2.26.4 bundle asset)

Both hit the identical Expected 4, but was 3 fatal error, and identical rejection of every literal 4th-column value tried.

Why this looks like a real bug, not user error

This is the same failure class as github/codeql-action#2706 (sourceModel arity mismatch, C#, "Expected 10, but was 9"), which was triaged as a genuine bug and fixed upstream, not a documentation/config issue on the reporter's side.

Impact

We currently work around this with continue-on-error: true on the analyze job, which means our repo has had no functioning CodeQL security scanning at all (all languages, not just the one with the custom model) since the analyze step fatally errors before any queries run.

Ask

• Confirm whether barrierModel genuinely requires a 4th user-supplied column at these CLI versions, and if so, document the correct literal value for it.
• If it should only take 3 columns (matching the documented examples and sourceModel/sinkModel's pattern), this looks like a packaging/version-skew bug between the compiled query pack and the python-all/javascript-all library pack.