oscerd opened a new pull request, #25430: URL: https://github.com/apache/camel/pull/25430
`listCollections` was the only document operation that read the document id straight from the header: ```java String documentId = exchange.getIn().getHeader(GoogleFirestoreConstants.DOCUMENT_ID, String.class); ``` Every other operation goes through `determineDocumentId(exchange)`, which falls back to the `documentId` endpoint option. So `google-firestore:users?documentId=alice&operation=listCollections` silently listed the **root** collections instead of the sub-collections of `users/alice`. The lookup now falls back to the configured id as well, while keeping what makes this operation different: a missing id still means "list the root collections", so it must not fail the way `determineDocumentId` does. That is `determineListedDocumentId`, covered by the new test. Also in this PR: `queryCollection` and `listDocuments` added their `_id`/`_path` entries to the map returned by `QueryDocumentSnapshot.getData()` — the object the SDK handed us. They now copy it first. The body content is unchanged. **Not addressed here** (from the same audit, needs a maintainer call on the policy): the realtime consumer queues snapshot changes in an unbounded `ConcurrentLinkedQueue` that is only drained per poll, so a collection changing faster than the route consumes grows it without limit. Bounding it means choosing an overflow policy — dropping changes or blocking the Firestore callback thread — and `google-firestore` exposes no `maxMessagesPerPoll` today. I left a note on the JIRA issue. _Claude Code on behalf of oscerd_ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
