Skip to content

fix: preserve behavex absolute timestamps when replaying JSON#494

Merged
gibiw merged 2 commits into
mainfrom
fix/behavex-real-timestamps
May 26, 2026
Merged

fix: preserve behavex absolute timestamps when replaying JSON#494
gibiw merged 2 commits into
mainfrom
fix/behavex-real-timestamps

Conversation

@gibiw
Copy link
Copy Markdown
Contributor

@gibiw gibiw commented May 25, 2026

Summary

  • QaseFormatter.launch_json_formatter consumes the consolidated BehaveX JSON report and currently synthesises timestamps from duration and now() — every scenario ends at the moment of replay and starts at now() - duration. Scenarios that BehaveX actually executed 200 ms apart collapse onto the same instant in the TestOps timeline, and the order on the timeline matches parser iteration rather than real execution.
  • BehaveX records absolute start / stop (Unix ms) on every scenario and step. Use them: compute one time_offset so the earliest BehaveX scenario lands at the replay moment, then shift every scenario/step by that constant. The whole timeline ends up inside the run window the API accepts, worker parallelism survives, gaps between stages match the gaps BehaveX recorded.
  • Fall back to the legacy "now - duration" path only when start / stop are missing.
  • Drive-by: scenario_dict.get('background', {}) returned None when the key existed with a null value (exactly what BehaveX writes for scenarios without a background), and the following .get('steps') raised AttributeError. Use or {} so a null background is treated as empty.
  • Bumps qase-behave to 3.2.1.

Test plan

  • Added TestBehavexAbsoluteTimestamps in test_utils.py (4 cases): scenario uses real start/stop+offset; scenario without start/stop falls back to now; step uses real start/stop+offset; three scenarios spaced 200 ms apart preserve the gaps after offsetting.
  • Added TestComputeTimeOffset in test_formatter.py (3 cases): empty features → 0.0; scenarios without start → 0.0; offset lands the earliest scenario near now().
  • Added test_launch_json_formatter_survives_null_background covering the drive-by NPE.
  • pytest qase-behave/tests/ -v → 80 passed locally (Python 3.12).
  • End-to-end verified against TestOps project DEVX with a synthetic 3-scenario BehaveX JSON spaced 0 → +200 ms → +600 ms:
    • Before fix (run #883): all 3 scenarios end at the same timestamp 18:01:52.
    • After fix (run #884): scenarios end at 18:23:05, 18:23:05, 18:23:06 — real ordering and gaps preserved.
  • CI green on all supported Python versions.

gibiw added 2 commits May 25, 2026 21:27
When QaseFormatter.launch_json_formatter consumed the consolidated
BehaveX JSON report, parse_scenario_from_json and parse_step_from_json
synthesised timestamps from the recorded duration and the current
time: every scenario ended at now() and started at now() - duration.
Scenarios that BehaveX actually executed 200 ms apart all collapsed
onto the same moment in the TestOps timeline, with timeline ordering
matching parser iteration rather than real execution order.

BehaveX records absolute ``start`` / ``stop`` milliseconds on every
scenario and step. Use them: compute a single time_offset such that
the earliest BehaveX scenario lands at the moment we begin replay
(get_real_time()), and shift every scenario/step by that constant.
The whole timeline ends up inside the run window the API accepts,
worker parallelism survives, and the gaps between scenarios match
the gaps BehaveX recorded.

Fall back to the legacy "now - duration" path only when ``start`` /
``stop`` are missing.

Drive-by: ``scenario_dict.get('background', {})`` returned ``None``
when the key existed with a null value (which is exactly what
BehaveX writes for scenarios without a background), and the next
``.get('steps')`` raised AttributeError. Use ``or {}`` so a null
background is treated as empty.
@gibiw gibiw merged commit ed2fe6a into main May 26, 2026
37 checks passed
@gibiw gibiw deleted the fix/behavex-real-timestamps branch May 26, 2026 06:59
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