Commit 8d7ebee
fix(webapp): use derived friendlyId for parent metadata fan-out on buffered runs
Devin follow-up on PR #3756. The parent branch of the metadata route's
fan-out passed `bufferedEntry.parentTaskRunId` (an internal cuid) where
the rest of the route works in friendlyIds. `updateMetadataService.call`
does auto-detect internal vs friendly via `runId.startsWith("run_")` so
the lookup succeeded for the common case (parent materialised in PG),
but the inconsistency surfaced as soon as `readFallback.server.ts` was
fixed to derive `parentTaskRunFriendlyId` / `rootTaskRunFriendlyId`
from the snapshot's internal IDs via `internalRunIdToFriendlyId` — at
that point the parent path was the only consumer still passing the
internal id.
Switch the parent route to `bufferedEntry.parentTaskRunFriendlyId ?? runId`,
mirroring the root path's shape. The `?? runId` matches the PG service's
own self-fallback (`taskRun.parentTaskRun?.id ?? taskRun.id`) so a
top-level run's parent ops land on itself rather than being silently
dropped. Stale comment block about "parentTaskRunId is an internal id"
removed — both fields are now friendlyIds.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>1 parent 44da36e commit 8d7ebee
1 file changed
Lines changed: 15 additions & 9 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
210 | 210 | | |
211 | 211 | | |
212 | 212 | | |
| 213 | + | |
| 214 | + | |
| 215 | + | |
| 216 | + | |
| 217 | + | |
| 218 | + | |
| 219 | + | |
| 220 | + | |
| 221 | + | |
| 222 | + | |
213 | 223 | | |
214 | | - | |
215 | | - | |
216 | | - | |
217 | | - | |
218 | | - | |
219 | | - | |
220 | | - | |
221 | | - | |
222 | | - | |
| 224 | + | |
| 225 | + | |
| 226 | + | |
| 227 | + | |
| 228 | + | |
223 | 229 | | |
224 | 230 | | |
225 | 231 | | |
| |||
0 commit comments