dashboard: remember ai job correctness review history

[a-nogikh]

On the bug's page, display the history of job result changes.

[dvyukov]

I was thinking: do want this to be more generic "user action logging" thing so that we don't need to create table/helpers per each action? For example, we already have "bisection invalidation" button, we have reproducer submission to managers, now we also have AI job creation.
It could be a table with:

• entity type
• entity id
• action
• user
• date
• JSON with additional data

Then a single set of helpers to insert/retrieve actions for particular entity type/id.

[a-nogikh]

I am not sure we're going to have a great time journaling actions in Spanner for Datastore entities.

[dvyukov]

I am not sure we're going to have a great time journaling actions in Spanner for Datastore entities.

Why? Don't we just store a string ID, that's how we would store references in Datastore anyway.

[a-nogikh]

• No way to commit across two databases.
• No foreign key references enforcement - easy to forget to delete journal entries if the datastore entity is deleted.
• I think that, in Datastore, the more natural way would be to keep history in a field inside an entity itself.

we have reproducer submission to managers

That is de facto already logged: https://github.com/google/syzkaller/blob/master/dashboard/app/entities_datastore.go#L731

In terms of non-AI part of syzbot, I think a more interesting target for journalling would be the user commands sent to the bugs (#syz invalid, #syz dup, #syz fix etc). These are mostly scattered across different mailing lists/other reporting targets, so once one needs to see the history, it may actually be quite challenging to gather it all.

[dvyukov]

What do you think about the spanner part (e.g. AI job creation requests, and anything else we may have in the future, esp when it's opened to public)? Since it's database, it better to think about the format ahead of time.

[a-nogikh]

I think the stakes are not super high here - we'll have a limited set of actions/tables anyway, and in the worst case we could afford a more tricky migration.

We could introduce Action and Details fields and rename it to Journal. For now, it already has JobID. We could make it nullable, and if there turn out to be other related entities, we could add them as extra columns as well. Then we'll get automatic consistency checks.