Repository navigation
Conversation
There was a problem hiding this comment.
🟢 Approval recommended
The narrowly scoped dispatch change has targeted regression coverage and no identified blocking issues.
No open issues 🎉
What changed in this PR
This update corrects aggregate command dispatch in the library, with focused regression coverage for write-stage error reporting.
Changes:
- Keeps the generic-command fallback for non-primary read preferences.
- Adds
$outand$mergeregression cases that assert the reported exception code is79.
| File | Description |
|---|---|
tests/UnifiedSpecTests/UnifiedSpecTest.php |
Registers the write-concern-error suite with a temporary incomplete marker. |
tests/Operation/AggregateFunctionalTest.php |
Tests error reporting for both write stages with an explicit primary read preference. |
src/Operation/Aggregate.php |
Removes the primary read preference from execution options to select read-write dispatch. |
Review effort: Balanced
❌ 17 Tests Failed:
View the full list of 17 ❄️ flaky test(s)
To view more test analytics, go to the Test Analytics Dashboard |
9ef7fc2 to
2feac4d
Compare
Aggregate fell back to Server::executeCommand() whenever a read preference was set. Collection always sets one, so a writeConcernError returned for a pipeline ending in $out or $merge was never reported. A primary read preference is the default for executeReadWriteCommand(), so drop it and use that method, which reports the error. Other read preferences still use executeCommand(), because the extension has no command path that both honours a read preference and parses writeConcernError. Enable the write-concern-errors spec tests, update tests/specifications to the merged DRIVERS-3684 specification, and support the dropDatabase and dropIndexes operations in the unified test runner.
Fix PHPLIB-1977
Why aggregate:
Collection::aggregate()always passes a read preference, so every write-stage aggregate ($outor$merge) went throughServer::executeCommand(). libmongoc does not parsewriteConcernErroron generic commands, so the error was never reported. A primary read preference is now dropped so the command usesServer::executeReadWriteCommand(), which reports it. Other read preferences keep the current path, since the extension has no command method that both honours a read preference and parseswriteConcernError.Specifications:
tests/specificationsmoves to the merged DRIVERS-3684 specification, mongodb/specifications#1998 (mandate the reporting) and mongodb/specifications#2003 (adderrmsgto the failpoints). Thewrite-concern-errorssuite is enabled, withdropDatabaseon a client anddropIndexeson a collection added to the unified test runner. ThemapReducetest stays skipped because PHPLIB has no mapReduce API.Extension: consistent
writeConcernErrorreporting for the other write APIs comes from mongodb/mongo-c-driver#2517 (CDRIVER-6523), included in libmongoc 2.5.8 and shipped by ext-mongodb 2.5.6. That fix only covers cursor-based commands such asmongoc_collection_aggregate, so the library still needs this dispatch change.