Skip to content

Honour skip_module_check when filtering failures by extension module - #22

Open
dionmcm wants to merge 1 commit into
groups-api-fixfrom
port-skip-module-check
Open

Honour skip_module_check when filtering failures by extension module#22
dionmcm wants to merge 1 commit into
groups-api-fixfrom
port-skip-module-check

Conversation

@dionmcm

@dionmcm dionmcm commented Aug 18, 2026

Copy link
Copy Markdown
Member

Port of upstream 051e87e (VAL-531).

What upstream fixed

An extension validation discards any failure whose moduleId is outside the configured module list. That is right for assertions reporting failures against arbitrary components, but wrong for assertions that have already worked out which modules their failures concern — their rows were dropped even though the assertion had deliberately selected them. Upstream lets an assertion mark its own rows exempt by writing qa_result.skip_module_check, which the extractor then honours.

Why this matters to us concretely

It is not only a filtering improvement — on the catch-up corpus it is currently a hard execution failure. Two of arm F's five execution errors are exactly the assertions whose INSERT names this column:

eb7ccd3f  Term exists exactly once in each language refset for each concept in delta.
31f5e2c8  There is only one member id per description per dialect in the language refset snapshot file.

The column does not exist, so the insert fails and the assertion cannot run. This PR creates it — Hibernate builds it from the QAResult entity under ddl-auto=create, so schema and reader stay in step.

Why it is safe to land now, ahead of the corpus

Verified against both corpora:

check result
assertions writing the column in the pinned corpus fad36466 0
assertions writing it in the catch-up corpus 0160dd2 4 INSERTs across 3 files
any of those among the 544 assertions production runs? no (checked against daily-rvf 15945's report)
INSERTs using positional VALUES that a new column would break 0 — every INSERT in both corpora names its columns

So on today's nightly the column reads back NULL, getBoolean yields false, and every row goes through the module filter exactly as before. Landing the engine change first means the corpus bump does not have to carry an engine change with it.

Note on fidelity to upstream

MysqlFailuresExtractor has diverged here (Collectors.toList rather than .toList(), inlined limit), so the predicate is ported by meaning rather than as a literal diff. The entity and DTO changes match upstream exactly, including making FailureDetail Serializable — which also gives the pre-existing transient on tableName a meaning it did not have.

Testing

mvn test — 88/88 green. The behavioural claim is under test in a full local run (arm H = this branch + catch-up corpus), whose prediction is execution errors 5 → 3, clearing exactly the two assertions above.

🤖 Generated with Claude Code

https://claude.ai/code/session_018aYBXcyiozxQQGhzzhS7KG

Port of upstream 051e87e (VAL-531).

An extension validation discards any failure whose moduleId is outside the
configured module list. That is right for assertions that report failures
against arbitrary components, but wrong for assertions that have already
worked out which modules their failures concern - their rows were being
dropped even though the assertion had deliberately selected them.

Upstream's fix lets an assertion mark its own rows exempt by writing
qa_result.skip_module_check, which the extractor then honours.

Behaviourally inert on the corpus we currently pin (fad36466): no assertion
there writes the column, so it reads back NULL, getBoolean yields false, and
every row still goes through the module filter exactly as before. Verified
against both corpora - the four INSERTs that set it live in three files
(delta-language-unique, snapshot-language-referencedcomponent-unique-per-refset,
and the inactivated-component-module stored proc), all of which arrive with the
catch-up corpus 0160dd2 and none of which are among the 544 assertions
production runs today. Landing the engine change first means the corpus bump
does not have to carry an engine change with it.

Every INSERT in both corpora names its columns explicitly, so adding a column
to the entity cannot disturb them. The column itself is created by Hibernate
from this entity (ddl-auto=create), so schema and reader stay in step.

MysqlFailuresExtractor differs from upstream here (Collectors.toList, inlined
limit), so the predicate is ported by meaning rather than as a literal diff.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018aYBXcyiozxQQGhzzhS7KG
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