Skip to content

_shared_dimension picks its dimension by iterating a set, so a tie can resolve differently between processes #202

Description

@sandeep-agami

Found during ACE-083 review (#199). Pre-existing on main @ 439ecd1; ACE-083 narrows the window (its scope filter shrinks table_set) but does not close it.

F11 §3 is explicit: "the same SQL against the same model version produces the same findings, in the same order, in every process."

runtime.py::_shared_dimension picks the shared dimension for a chasm finding by walking table_set, which is a set. Where two candidate dimensions both qualify, which one is picked depends on iteration order, and therefore on PYTHONHASHSEED. The fan branch was deliberately given sorted() for exactly this reason; the chasm side's dimension pick was not.

The current _sales_org fixture has one candidate dimension, so no test can exercise it today. A repro needs a model where two tables both face the measure tables.

Related and already fixed in #199, so do not confuse them: three sorted() calls in _preflight_select (the chasm agg_sources, the fan loop's agg_sources, and many_tables) were unguarded by any test, and test_the_aggregate_report_is_the_same_in_every_process now catches the removal of each one by mutation. This issue is the fourth site, which has no sorted() at all.

Fix is to make the pick deterministic (sort the candidates, or state a tiebreak), plus a fixture with two qualifying dimensions and a subprocess probe over several hash seeds, following the idiom in tests/test_ace083_trap_soundness.py::test_the_aggregate_report_is_the_same_in_every_process.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions