Salesforce implementation containing read and write operations#4151
Conversation
Co-authored-by: Joseph Woodward <joseph.woodward@xeuse.com>
Co-authored-by: Joseph Woodward <joseph.woodward@xeuse.com>
…ics.go Co-authored-by: Joseph Woodward <joseph.woodward@xeuse.com>
Co-authored-by: Joseph Woodward <joseph.woodward@xeuse.com>
Co-authored-by: Joseph Woodward <joseph.woodward@xeuse.com>
Co-authored-by: Joseph Woodward <joseph.woodward@xeuse.com>
Co-authored-by: Joseph Woodward <joseph.woodward@xeuse.com>
Co-authored-by: Joseph Woodward <joseph.woodward@xeuse.com>
| @@ -0,0 +1,379 @@ | |||
| // Copyright 2026 Redpanda Data, Inc. | |||
There was a problem hiding this comment.
With the utmost deference to the esteemed contributors, this humble automaton wishes to note a gap in the test suite.
No concurrent WriteBatch tests for bulk mode
The existing tests in this file exercise configuration validation, CSV serialisation, single-goroutine write paths, and response parsing — all most commendable. However, there are no tests that call WriteBatch concurrently, which is precisely the scenario that arises when max_in_flight > 1.
The esteemed @josephwoodward has already identified concurrency concerns in the bulk path (the TOCTOU capacity check and the drainCompletedBulkJobs / errCh interaction). Concurrent tests would both verify any fixes and serve as regression guards.
A test that launches N goroutines calling WriteBatch simultaneously against a mock HTTP server — asserting that peak concurrent Salesforce job-creation requests never exceeds maxBulkJobs — would exercise the critical section directly. (The esteemed @josephwoodward has in fact provided a sketch of such a test in an earlier comment on this PR, which could serve as a starting point.)
Co-authored-by: Joseph Woodward <joseph.woodward@xeuse.com>
3 participants
No description provided.