Repository navigation
Fix false first_reply_time breaches when an agent replies before Zendesk delays the clock (v1.9.1) - #287
Closed
fivetran-catfritz wants to merge 2 commits into
Closed
Fix false first_reply_time breaches when an agent replies before Zendesk delays the clock (v1.9.1)#287fivetran-catfritz wants to merge 2 commits into
fivetran-catfritz wants to merge 2 commits into
Conversation
…tes it (v1.9.1) #278 correctly delayed sla_applied_at to Zendesk's logged clock start, but an agent can reply publicly before that point (Zendesk delays the clock until the customer's own first public comment, not the agent's). That early reply was being ignored, and the model would wait for the agent's *next* reply, producing a false breach. sla_applied_at for first_reply_time now anchors at ticket creation whenever a public agent/admin reply already exists before the logged instance, which covers both this case and the #279 re-application case through the same mechanism. Replaces the #279 fix's "earliest logged instance" check with a simpler, more precisely scoped "earliest already-given reply" check, since that's what's actually evidenced: Zendesk marks the metric met once a reply has already happened, not simply whichever instance was logged first. Verified against 4 real tickets reported in a reopened customer complaint (420358, 407147, 360783, 331197) — all now resolve to met. Checked the broader population in digital-arbor-400.zendesk_new: 714 tickets flip from falsely breached to met, zero regressions in the other direction (the fix can only move a ticket toward met). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
fivetran-catfritz
deleted the
bug/early-agent-reply-before-delayed-sla-start
branch
October 21, 2026 15:49
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Context
A reopened customer complaint surfaced 4 tickets still showing false
first_reply_timebreaches after v1.9.0. All 4 share the same pattern: an agent already replied publicly, but Zendesk hadn't started thefirst_reply_timeclock yet because the customer's own first public comment hadn't happened (the delayed-start behavior #278 correctly started reading directly from Zendesk). Once the clock did start, the model searched forward for the agent's next reply instead of recognizing the earlier one, producing a false breach.This is a regression introduced by #278, not a pre-existing issue — confirmed directly:
ticket.created_atfor all 4 tickets exactly matches their first (private) comment, which is whatsla_applied_atused before #278. The agent's early public reply landed between that old anchor and the new (correctly delayed) one, so these tickets resolvedmetbefore #278 andbreachafter.Fix
sla_applied_atforfirst_reply_timenow anchors at ticket creation whenever a public agent/admin reply already exists before the logged instance. This replaces the #279 fix's "earliest logged instance" check with a simpler, more precisely scoped "earliest already-given reply" check — covering both this case and #279's re-application case through the same mechanism, since what's actually evidenced is that Zendesk marks the metric met once a reply has already happened, not simply whichever instance was logged first.Single file changed:
int_zendesk__sla_policy_applied.sql.Verification
metagainst real data indigital-arbor-400.zendesk_new, matching the originally-reported expectation.met, no regression.first_reply_timetickets): 714 tickets flip from falsely breached to met, and zero tickets move the other direction — this fix can only ever move a ticket towardmet, unlike False first_reply_time SLA breach when Zendesk re-logs the SLA after the team already replied #279's fix which also surfaced previously-hidden true breaches.Release
Patch (v1.9.1): this corrects a defect in the just-shipped v1.9.0 behavior rather than changing long-stable behavior.
🤖 Generated with Claude Code