Skip to content

Conversation

@adriansberg
Copy link
Collaborator

Implement handling for Shmo booking update events in the event stream, allowing the application to invalidate queries related to active Shmo bookings. Instead of setting a refetchInterval to poll the update of the price we now invalidate the active booking queries when an event of type SHMO_BOOKING_UPDATED appears in the event log.

related https://github.com/AtB-AS/kundevendt/issues/21932

@adriansberg adriansberg changed the title Add Shmo booking stream event handling feat: add Shmo booking stream event handling Nov 19, 2025
@adriansberg adriansberg changed the title feat: add Shmo booking stream event handling feat: add shmo booking stream event handling Nov 19, 2025
Comment on lines 31 to 33
queryClient.invalidateQueries({
queryKey: getActiveShmoBookingQueryKey(acceptLanguage),
});
Copy link
Member

@rosvik rosvik Nov 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we really need to pass a language here? Invalidating just "GET_ACTIVE_SHMO_BOOKING_QUERY_KEY" should invalidate queries using both languages.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, probably not? I saw that acceptLanguage is required in the query key, and assumed that it couldn't be undefined when used to invalidate either. Pushed a change that makes it optional now, and will test that some.

@adriansberg adriansberg force-pushed the adriansberg/shmo-booking-updated-stream branch from ee53e43 to f77fdd1 Compare November 20, 2025 08:37
Copy link
Member

@rosvik rosvik left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me 👍

Copy link
Contributor

@Dahly96 Dahly96 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look okey, after previous comments are addressed.

One question that might be irrelevant, but are we not receiving the booking data with the event? Could it be set instead of us invalidating and refetching it?

@adriansberg
Copy link
Collaborator Author

Changes look okey, after previous comments are addressed.

One question that might be irrelevant, but are we not receiving the booking data with the event? Could it be set instead of us invalidating and refetching it?

We could, but that would require quite the rewrite, and I think we should think that through in a CODEv or something how we want to implement such handling, so that we have a agreed upon solution for the future.

@marius-at-atb
Copy link
Collaborator

@Dahly96 Excellent question! Yes, it could be that we should do that. Was thinking to talk about it with the Entur team first to be sure about the content of the events, hopefully in tomorrow's meeting.

@marius-at-atb
Copy link
Collaborator

Btw that's not a blocker for this PR. In the first round of event handling, it's simplest and safest to start with just ids and invalidation. So if we go for full event data, it should be added later anyway.

@adriansberg
Copy link
Collaborator Author

@marius-at-atb 100% agree, and like my previous comment we all should be aligned for how we proceed with a shift like that. 😀

Copy link
Collaborator

@marius-at-atb marius-at-atb left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants