Skip to content

Fix behavioral eval cases that fail on unrelated PRs #2413

Open

Description

@sentry-junior

Some behavioral eval cases fail or error on most PRs, including PRs that do not touch product code. The evals summary check goes red when any case fails or errors, so these cases make the check red on almost every PR. Reviewers then learn to ignore it.

Seen on #2371, #2374, #2376, #2377 and #2410:

  • evals/google/scheduling.eval.ts: "when a recurring slot is for two people and the requester's afternoons are holds, check both and propose a time". It errors with STACK_TRACE_ERROR on almost every run, and sometimes hits the 60s idle timeout. fix(google): Let the requester be optional in findMeetingTimes #2375 fixed a related findMeetingTimes bug, but not this error.
  • evals/agent/delegation.eval.ts: "when a request splits into independent research tracks, start a child agent for each track". It often hits the 60s "agent not idle" timeout.
  • evals/google/scheduling.eval.ts: "when the requester corrects a one-sided answer, check the other attendee without asking again". It sometimes hits the 60s timeout.
  • evals/coding/subscriptions.eval.ts: "looks up and subscribes to an exact deployment before GitHub creates it". It fails on some runs.

For each case, find out whether:

  • the product has a bug (fix the product),
  • the eval checks wording or needs the model to do something wrong (fix the eval, following policies/evals.md; do not rewrite the user's message to make it pass), or
  • the 60s idle limit is too short for a task that needs several tool calls (change the limit for that case, with a reason).

Do not skip or remove a case only to make the check green.

via David Cramer.

--

View Session [Sentry]

Activity

  1. sentry-junior commented on Oct 30, 2026

    @sentry-junior
    ContributorAuthor

    Recurring two-person slot: use case and proposed change

    The use case. This case copies a real thread. The requester and Sam want a weekly 90-minute slot on Wednesdays and Fridays, early afternoon, to stream pairing. The requester blocks every afternoon with "DNS" (do not schedule) events so other people don't book over them. They are now booking into that time themselves. The requester still attends. Only their calendar is the wrong signal for this window. The real availability comes from what they said ("generally free 1–5pm"). Sam's calendar is the real constraint.

    Why the tool doesn't fit it. Two gaps in findMeetingTimes:

    1. "These busy times are holds" has no field of its own. The only way to say it is to list the requester in optionalAttendees. That field means "people the requester calls optional". The requester is not optional, so the model has to say something false to get the right result. It did that in 1 of 178 calls. In the follow-up case, where the thread says outright that the blocks are placeholders, it does use the field and passes. My reading is that the name of the field is part of the miss. That is inference.
    2. No weekday filter. The user asked for Wednesdays and Fridays. The tool searches every weekday and spreads results across days. With the default maxResults: 3, the first results can all fall on Mon/Tue/Thu. The only way to scope to Wed/Fri is one call per day. That fits the 4–6 retries per run that end at the 60 s limit.

    Proposed change (one PR in junior-google, required-by-default unchanged):

    • holds: string[]: attendees who said the busy times on their calendar in this window are holds they can move. They stay attendees and keep their working hours. Their busy times don't block a slot. Slots that avoid them come first. A slot that overlaps them lists the person in holdConflicts. Remove the "put the requester here" line from optionalAttendees, so that field only means optional people.
    • weekdays: ("Mon"…"Fri")[]: only return slots on these days.
    • Tests: extend the main findMeetingTimes test in tests/calendar.test.ts for both inputs. No new eval case and no change to the user message. Proof is a few live runs of this case on the branch that propose 1:30–3:00 PM PT within 60 s.

    Out of scope: making one time fit every week. The model can still compare the Wed and Fri results.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions