and i imagine that the difficult part of it is going to be the plumbing, not constructing the SQL query

Hey! I've finished the implementation for #2056. Before I open the PR, just wanted to give a quick heads up on what I did in case anything looks off: - Added a

LookupDebugTrace

proto message and wired it across all 3 Lookup dispatch paths (LR2, LR3, LookupSubjects) - Added a

traversalTracker

in the request context that's zero-cost when debug tracing isn't enabled - Enabled via the same

requestmeta.RequestDebugInformation

gRPC header that Check already uses - 6 unit tests + 2 integration tests, all passing Happy to adjust anything before it goes up for review!

the approach you took of sticking it in a trailer is what we used to do

but we quickly ran into size limits for gRPC trailers

which led to us moving it inboard and into the proto API

our current thought is that rather than having a

LookupDebug

object, we're going to move to a new structure for `DebugInformation`: https://github.com/authzed/api/issues/163

and then we'll reuse this general-purpose

DebugInformation

shape across our various APIs

is that something you'd be keen to work on?

makes sense. Here's my plan: For authzed/api: add the V2 DebugInformation structure from #163 - DebugTree, DebugScope, DebugInformationV2 with the google.protobuf.Any annotations map. Also add a LookupCycleAnnotation message that carries the visited-node data. Wire DebugInformationV2 as an optional field on LookupResourcesResponse and LookupSubjectsResponse. For the SpiceDB PR: strip the trailer code entirely, keep the internal traversalTracker machinery, and in permissions.go convert the snapshot into a DebugInformationV2 with a "lookup_cycles" scope after each dispatch stream closes, same pattern as ConvertCheckDispatchDebugInformation does for Check. Set it on the last streamed response. One thing I need to confirm before wiring permissions.go: for the streaming responses, should the debug field go on the last streamed message, or does it need a separate terminal message? Wanted to check before assuming it follows the same convention as Check.

and once the api changes go in we can move them into authzed-go pretty quickly

pushed the pr at api , please check it out and tell me if any changes are needed , will start working on spice db part now

heyy , sorry about that merge conflict , resolved them , please do tell me if any other changes are needed

i'm thinking about what the associated user experience would be, like in

zed

for example

the ask from users seems to be "i have a MaxRecursionDepthExceeded error and i want to know why"

it seems like a good way to do that might be something that's functionally a stack trace - when you hit the error, you start walking back up the stack and collecting all of the relationships and permissions that you've walked through

the upsides being that it's relatively easy to display and understand (and marking the cycle points can be a part of this if desired, but i don't think it's even completely necessary)

and it also means that you don't need to eagerly construct the entire tree associated with the walk, but rather can do it lazily when you hit the error

it should also make it easier to deal with subject relations - i haven't looked closely enough at your code to understand what it's doing with LS yet

but yeah my thought is that the trace becomes a list of (v1.Relationship, internalv1.Permission) pairs (or something like that? i'm not sure how permissions/relations are represented internally)

so that you can see both the data and schema elements involved

does that make sense to you? i appreciate all of the work you've put into it so far, and you can tell me if you get to a place where you're tired of working on it

Framing it around understanding the error makes this clearer in a ux perspective and the approach is cleaner than what I had done

But before I get to reworking the implementation I had a few questions

Should it be available only when the max recursion depth exceeded is fired or even under the debug/explain modes

For each frame

is the expectation to capture the concrete relationship tuple being followed along with the permission/relation name at that step?

is it enough to show the repeated step in the trace, or do you want an explicit marker in cycles ?

I’ll hold off on reworking the PR until I confirm the exact shape, but happy to pivot in this direction.

And thanks for the concern , will tell you if I'm facing any issues, currently I have no problem working but just a small heads up that I will not be available next week... I have exams till May 27th but the next week will be hectic specifically... 3rd year of college will be done after this 🥳

And also , if there is something else which is a slightly higher priority (if you feel I can do it) then do let me know as there is not much time before next week to be specific the coming Saturday night onwards I'll be busy , so yea if anything else slightly higher in priority or anything else you would want me to pivot to please do let me know

> is the expectation to capture the concrete relationship tuple being followed along with the permission/relation name at that step? yeah, the proto for the relationship (if it's available at the place where you're doing the construction), because that seems like it'll be the most straightforward way to provide the necessary context to the user for them to be able to fix the issue

> is it enough to show the repeated step in the trace, or do you want an explicit marker in cycles ? I was talking about this with my coworker - i think for a first iteration it'll be enough just to show the trace and let the user inspect it, and we can treat an explicit marker as a follow-on

sounds good - i know we have user interest in this work so we may get to a place where i pick it up to get it done. you'll still be on the PR/commits in that case.

So I’ll gate it behind the debug header, capture (relationship, permission/relation) frames during traversal, and surface the stack trace when the depth error occurs. I’ll keep it simple for now (no explicit cycle markers) and reuse the existing debug output shape.

I’ll update the implementation along those lines and commit it to the PR.

suree that works

Each frame now corresponds to a real traversal edge, and the trace is emitted only when max recursion depth exceeded occurs

with debug enabled

One tradeoff in the current version is that I split batched dispatches into per id dispatches

this ensures the trace shows actual execution path

This does introduce additional overhead compared to the original batched approach tho

i was just thinking we could look at preserving batching while maintaining per edge trace correctness if that’s preferred to proceed as an iteration to this

I'll update the pr and let you know

the test doesn't seem to be working as intended - i can't dump out debug info and see the contents of the trace. is there something i'm missing?

I'll make it visible through the debug pipeline similar to how check debug is exposed

This will make it visible through usual tooling and not inside the error metadata

I'll try working on it today

the error details approach seems correct

because the response is going to be an error in the case of depth exceeded

did you push your most recent changes? i wasn't seeing them when i was looking at it yesterday

I'll try getting to it now ,

pushed the changes and restored batched dispatch and decoupled the trace from execution, the trace is now maintained across traversal and attached via error details on max depth exceeded, so it should be visible when inspecting the error ,also fixed an issue where the stack was getting cleared before it could be read

let me know if you're able to see the trace now or if anything looks off

and a small thing is that for the pr as is the trace is more of a traversal history than a stack , i am working on that part right now

will push commit and let you know and you ca review it all together

pushed the latest changes

trace is attached via error details and should reflect the actual traversal path now

kept batched dispatch intact

switched to true stack semantics and now capture the trace at the point of max depth exceeded

could you take another look and see if you’re able to dump the trace now?

i picked up the implementation in https://github.com/authzed/spicedb/pull/3070. unless you have a strong objection, my plan is to get that PR reviewed and merged and then get the associated

zed

PR reviewed and merged. you'll still be marked as a contributor on the PR for your commits.

it was nice working with you 😁

happy to help with anything on this if needed