Kakfa Related Changes in Payload#6
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces comprehensive documentation for Kafka event schemas and their mapping to the Central DB, alongside a new survey template CSV. The ResponseService was updated to include context information and response data in Kafka events. Review feedback correctly identified missing responseId fields in the RESPONSE_STARTED and RESPONSE_SUBMITTED event payloads, which are necessary for consistency with the documentation. Additionally, the reviewer suggested refining the terminology from 'partial' to 'snapshot' when describing responseData in the documentation to better reflect that the full current state is sent.
| contextType: saved.contextType, | ||
| contextId: saved.contextId, |
There was a problem hiding this comment.
The responseId is missing from the data payload for the RESPONSE_STARTED event. To maintain consistency with the documentation in KAFKA_EVENTS.md (line 207) and other response events like RESPONSE_UPDATED, it should be included in the data object.
| contextType: saved.contextType, | |
| contextId: saved.contextId, | |
| responseId: saved.responseId, | |
| contextType: saved.contextType, | |
| contextId: saved.contextId, |
| contextType: saved.contextType, | ||
| contextId: saved.contextId, |
There was a problem hiding this comment.
The responseId is missing from the data payload for the RESPONSE_SUBMITTED event. This contradicts the documentation in KAFKA_EVENTS.md (line 263). Including it ensures consistency across all response events.
| contextType: saved.contextType, | |
| contextId: saved.contextId, | |
| responseId: saved.responseId, | |
| contextType: saved.contextType, | |
| contextId: saved.contextId, |
| ``` | ||
|
|
||
| > `respondentId` is **not included** in this event — look up the existing row by `responseId` to get it. | ||
| > `responseData` here is **partial** — only fields answered so far. Always check `status` before using it for reporting. |
There was a problem hiding this comment.
Describing responseData as "partial" in the RESPONSE_UPDATED event is slightly misleading. Since the service merges updates and sends the full current state of the response data, it is more accurate to describe it as a "snapshot" or "current state". This clarifies that the consumer receives the full set of answers collected so far, rather than just a delta of the changes.
| > `responseData` here is **partial** — only fields answered so far. Always check `status` before using it for reporting. | |
| > `responseData` here is a **snapshot** of all fields answered so far. Always check `status` before using it for reporting. |
| | Kafka Event | Action | | ||
| |---|---| | ||
| | `RESPONSE_STARTED` | **INSERT** — SurveyTrackingID, SurveyID, TenantID, TargetRoleUserId, Context, ContextId, Status = `in_progress`, CreatedAt, SurveySummary = `null` | | ||
| | `RESPONSE_UPDATED` | **UPDATE** — Status, Context, ContextId, SurveySummary = partial responseData, UpdatedAt | |
There was a problem hiding this comment.
The term "partial" here should be updated to "snapshot" or "current state" to match the actual behavior of the producer, which sends the full merged state of the response data in the RESPONSE_UPDATED event.
| | `RESPONSE_UPDATED` | **UPDATE** — Status, Context, ContextId, SurveySummary = partial responseData, UpdatedAt | | |
| | `RESPONSE_UPDATED` | **UPDATE** — Status, Context, ContextId, SurveySummary = snapshot responseData, UpdatedAt | |
1 participant
No description provided.