[#1415] Inconsistency in nextAppointmentDateStr vs Available Slots – API Bug

Migrated from Redmine #1415 | Author: Andres Rios
Status: New | Priority: Immediate, there is BUG! | Created: 2025-05-21


We’ve found a reproducible inconsistency between the nextAppointmentDateStr field returned in the provider listing and the actual available slots returned via the detailed slot availability API.

This leads to incorrect availability being shown to end users — specifically, the system reports an available date that doesn’t actually have any bookable slots.

Steps to Reproduce (using test providers in your system):

Query the getAvailableProviders (or equivalent) endpoint for any provider and service.

Expected Behavior:

The nextAppointmentDateStr value should point to a date that actually has at least one bookable slot, as returned by the slot availability endpoint.

Actual Behavior:

The nextAppointmentDateStr value points to a date with no available slots.

When users tap on that provider expecting to book on that date, no slots are available, generating frustration and support tickets.
You’ll receive the field nextAppointmentDateStr (e.g., 2024-06-10).

Using the same provider ID and service ID, query the getProviderAvailableSlots (or equivalent calendar endpoint).

You’ll find that:

The date returned in nextAppointmentDateStr (2024-06-10, in this case) is not present among the available slots.

The real next available slot might be several days later (e.g., 2024-06-20).

Redmine Admin wrote:

hi, thank you for your feedback. For optimization purposes nextAppointmentDateStr do not check the dates too far in the future (this period depends on your settings, timeframe, etc.) and might not be able to find available slot if you don’t have it in near future. It is correct behaviour

Andres Rios wrote:

Redmine Admin wrote in #note-1:

hi, thank you for your feedback. For optimization purposes nextAppointmentDateStr do not check the dates too far in the future (this period depends on your settings, timeframe, etc.) and might not be able to find available slot if you don’t have it in near future. It is correct behaviour

*Hi, thank you for responding. The problem raised is that today this endpoint doesn’t return the correct date (the date sending today is actually not available in the user’s calendar), not the revision of future dates. The dates I put were just an example.
*