This repository was archived by the owner on Sep 30, 2024. It is now read-only.
[Backport 5.2] Surfaces errors in autoindex configuration#59756
Merged
Conversation
Co-authored-by: Varun Gandhi <varun.gandhi@sourcegraph.com> (cherry picked from commit f92302f)
Contributor
unknwon
approved these changes
Jan 23, 2024
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #58453
Test plan
Add the
vitejs/viterepo to your local sg instance, and view the autoindex configuration page.After this PR you should see the real error:
Error fetching index configuration: Inference limit: requested content for more than 100 (100) filesinstead of a nil pointer exception.
Implementation notes
I added two commits, but the first is completely overridden by the second. In 67ed1c3 I tried to 'interpret' what the code was trying to do in the first place, and return a 'succesful' result even if the evaluation ran into a limit error. That produces very confusing UX though, because now it looks like everything is fine on the configuration page, but there are no build jobs. I think it's better to surface the error in the UI here.
This change leaves things in a bit of an awkward spot. The assignment to
limitErris dead code. I don't think the special handling for limit errors make sense here, and it doesn't work anyway (because somewhere on the code path it's not treated different from other errors). I tried ripping it out, but my go-foo isn't quite there yet. I could either open an issue for the follow-up cleanup, or we could try to pair on it @varungandhi-src WDYT?Backport f92302f from #58879