Skip to content

fix(test): make clone stage dominance independent of real wall-time races #1650

Description

@DecisionNerd

Verified blocker

While validating #1623, cargo test --workspace --exclude graphforge-api --exclude graphforge-storage --no-fail-fast failed hub_clone::tests::both_identity_forms_import_and_reopen_the_same_real_project: the dominant component was PortableImport, but the assertion expected NetworkTransport. The CLI library reported 72 passed, 1 failed, 1 ignored. All nine real clones and facade reopens had completed before this final assertion.

The test injects a two-second sleep into each selected stage, then assumes that stage must have the largest real wall time. Real import, filesystem work, and scheduling have no two-second upper bound. The timing logic and test are unchanged from the base revision; the same test passed in native coverage. This is an invalid timing assumption, not proof that cloning returns incorrect data.

Bounded repair

Use a deterministic clock for the stage timing and injected-work attribution assertion. Keep the real durable import/reopen and receipt/handoff proof. Keep the real production clock and production behavior unchanged. Do not increase sleeps, retry the test, serialize the suite, remove the ranking assertion, or weaken its expected component matrix.

Acceptance criteria

  • All five injected-work cases deterministically select the expected dominant component without depending on host load or filesystem latency.
  • Real clone, receipt, handoff, privacy, fail-open output equivalence, and facade reopen assertions remain.
  • Production stage timing still uses the ordinary monotonic clock.
  • Targeted CLI tests, applicable full validation, and exact-head CI pass before merge.

This isolates a verified test blocker to #1623; it changes no ingest region and no performance policy.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions