-
Notifications
You must be signed in to change notification settings - Fork 7
Permalink
Choose a base ref
{{ refName }}
default
Choose a head ref
{{ refName }}
default
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
base repository: DataDog/dd-sdk-swift-testing
Failed to load repositories. Confirm that selected base ref is valid, then try again.
Loading
base: 2.7.5
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
...
head repository: DataDog/dd-sdk-swift-testing
Failed to load repositories. Confirm that selected head ref is valid, then try again.
Loading
compare: 2.7.6
Could not load branches
Nothing to show
Loading
Could not load tags
Nothing to show
{{ refName }}
default
Loading
- 5 commits
- 19 files changed
- 3 contributors
Commits on Jun 19, 2026
-
Fix flush race: seal writer on shutdown so in-flight writes aren't lo…
…st (#284) * Fix flush race: seal writer on shutdown so in-flight writes aren't lost The final flush at shutdown could skip (and permanently lose) a file that was being written concurrently. `FilesOrchestrator` hides files in `activeWrites` from the reader so the periodic upload worker never reads a half-written file. That's correct mid-session — the file is picked up on the next cycle — but at shutdown there is no next cycle: the worker is stopped right after the flush, so a file still in `activeWrites` during the final enumeration is stranded on disk, never uploaded. The window was a write submitted concurrently with the flush. Writes submitted before flush were already safe (serial writer queue + barrier in `closeCurrentFile`). Fix: - FileWriter.stop(): permanently seals the writer — drains in-flight writes via the serial-queue barrier, finalizes and closes the current file, then rejects all subsequent writes (logging the dropped event, with its encoded payload, for debugging). - FeatureStoreAndUpload.stop(): ordered teardown — stop scheduling uploads, then seal the writer, then run the final exhaustive flush. After sealing, no file can be in `activeWrites`, so the flush enumerates a complete set. - Exporter.shutdown(): drop the redundant pre-shutdown flush; each storage's stop() now performs the complete, race-free upload. A pre-stop flush could skip a file still being written that stop() would then never upload. - DDTracer.shutdown(): no longer pre-flushes — the OTel processor shutdown drains pending spans into the exporter (verified for both Simple and Batch processors) and the providers flush spans/logs/telemetry properly. Only the cross-process RUM port flush is forwarded, extracted into flushRUM(). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> * Inject logger into FileWriter; add stop()/seal regression tests FileWriter now takes a `log: Logger` (like DataUploadWorker) instead of the global `Log`, so callers pass the logger from the top and tests can capture log output without mutating global state. Wired `configuration.logger` / `config.logger` through at all four construction sites (spans, logs, telemetry, coverage). Tests (FileWriterTests): - write after stop() is dropped and logged with the encoded payload (asserted via an injected RecordingLogger) - stop() drains in-flight async writes before sealing - after stop(), getAllReadableFiles() enumerates the complete set — nothing hidden in activeWrites, modelling the final shutdown flush Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> * move network auto-instrumentation initialisation to the queue * increase priorities of the setup queues --------- Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for c211bea - Browse repository at this point
Copy the full SHA c211beaView commit details -
Seal active test/suite/module as failed on premature process exit (#285)
When the test process exits without XCTest delivering the completion hooks (testCaseDidFinish / testRetryGroupDidFinish / testSuiteDidFinish / testBundleDidFinish), the in-flight suite and test spans were never ended and so were dropped from the trace. This is not a crash — the process exits in an orderly way (e.g. a test calling exit(), or a failure in an async setUp/tearDown under recent Xcode), so the unload hook still runs and the session/module spans close, but everything below the module leaks. DDXCTestObserver.stop() previously did nothing (default: break) for the .suite/.group/.test states. It now detects the premature exit and: - logs a generic premature-exit warning (no vendor-specific attribution, since a user exit() produces the identical fault), - force-closes the open test and suite as failed with an explanatory PrematureTestProcessExit error, and - ends the module as testBundleDidFinish would; the failure propagates up to the session. State is extended so .group/.test carry the references needed to recover from stop() (previously they held none). Suite-end mirrors testSuiteDidFinish but skips the feature hooks, which can't run meaningfully at process exit. Adds a synchronous regression test driving the observer into .test and forcing shutdown. It is intentionally sync: stop() unregisters the observer, which XCTest only allows on the main thread, and async test variants either crash off-main or deadlock against XCTest's main-thread wait. SDTEST-3844 Co-authored-by: Claude Opus 4.8 (1M context) <[email protected]>Configuration menu - View commit details
-
Copy full SHA for e49c497 - Browse repository at this point
Copy the full SHA e49c497View commit details
Commits on Jun 23, 2026
-
Fix non-deterministic JSON key order causing Swift Testing args to be…
… misidentified (#286) * Fix non-deterministic JSON key order causing Swift Testing args to be misidentified Add .sortedKeys to apiEncoder outputFormatting so test argument dictionaries always serialize in a consistent order, preventing the same test from being treated as different tests across runs. Co-Authored-By: Claude Sonnet 4.6 <[email protected]> * Fix the actual source of non-deterministic argument serialization in Models.swift The apiEncoder change fixed key ordering in API payloads, but the test parameters tag is encoded via a separate plain JSONEncoder() in set(parameters:). Add .sortedKeys there so the JSONGeneric dictionary keys ("name", "value", "type") always appear in a stable order in test.parameters. Co-Authored-By: Claude Sonnet 4.6 <[email protected]> * Use apiEncoder for test parameters serialization Replace the standalone JSONEncoder with the shared apiEncoder which already has .sortedKeys (and other settings) configured. Co-Authored-By: Claude Sonnet 4.6 <[email protected]> * Simplify parameterized test assertions: drop TestParameters, compare raw JSON With apiEncoder's .sortedKeys the serialized test.parameters tag is fully deterministic, so there is no need to decode into a typed struct. Sort the raw JSON strings (lexicographic order matches the p1 int values) and compare directly against expected string literals. Co-Authored-By: Claude Sonnet 4.6 <[email protected]> * Make apiEncoder/apiDecoder public so cross-module callers can use them Co-Authored-By: Claude Sonnet 4.6 <[email protected]> --------- Co-authored-by: Claude Sonnet 4.6 <[email protected]>
Configuration menu - View commit details
-
Copy full SHA for 174c938 - Browse repository at this point
Copy the full SHA 174c938View commit details -
Configuration menu - View commit details
-
Copy full SHA for 3dd5144 - Browse repository at this point
Copy the full SHA 3dd5144View commit details -
Configuration menu - View commit details
-
Copy full SHA for 572cb0b - Browse repository at this point
Copy the full SHA 572cb0bView commit details
Loading
This comparison is taking too long to generate.
Unfortunately it looks like we can’t render this comparison for you right now. It might be too big, or there might be something weird with your repository.
You can try running this command locally to see the comparison on your machine:
git diff 2.7.5...2.7.6