I think it would be better to patch it it in the syz-ci code rather than in dashapi.

Thanks for the review - I'll get back to this PR soon. Before I make changes, I just wanted to explain my reasoning and double-check: based on https://go.dev/tour/methods/12, it sounds like interface methods with a pointer receiver often implement their own handling for the case of a nil receiver. I will go with whatever you prefer, though.

We already divert the logic in case of dash == nil in syz-ci:

Over time we probably just broke it since we don't use this mode anywhere and there are almost no syz-ci tests.

dash == nil disables significant chunks of syz-ci functionality, I think it's better to not even try to run those chunks of code in the first place rather that let them run with a dummy Dashapi implementation.

We already divert the logic in case of dash == nil in syz-ci

Just a note on this -- it was originally surprising to me that these dash == nil checks didn't result in early returns in the case of a nil dashboard. The explanation turned out to be in that golang reference above (https://go.dev/tour/methods/12): "Note that an interface value that holds a nil concrete value is itself non-nil". Since dash is an interface value, dash != nil even when the dashboard pointer is nil.

Indeed!

I think the bug was introduced recently with the ManagerDashapi interface -- before that it was only operating with *dashapi.Dashboard objects.

Hi! Hoping I can catch you today for a question:

Would you like DashboardAddr, DashboardClient, and DashboardKey to continue to be optional fields of syz-ci's Config as noted here?

It is nice to be able to start syz-ci (for testing / during development) without deploying a separate dashboard app, so I'd vote to make that possible somehow.

I think we should repair the non-dashboard mode and let those fields stay optional.

How exactly -- it depends on:

1. Whether there are cases when an if dash == nil check could have prevented unnecessary work we would still be doing with a dummy dashboard implementation. E.g. a syz-ci may upload build assets to GCS and push download links to the dashboard, which makes no sense at all if there's no dashboard to send the link to. Though in this particular case you probably wouldn't configure the asset storage either, so nothing will be uploaded anyway.
2. The size of the resulting code diff.

If the approaches are equivalent on both these factors, I don't have a strong preference.

Thank you! That makes sense. I'll spend some time reworking this today and upload a new version.