New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

getJSON fetch failure should not abort build #5643

Closed
anthonyfok opened this Issue Jan 27, 2019 · 5 comments

Comments

Projects
None yet
2 participants
@anthonyfok
Copy link
Contributor

anthonyfok commented Jan 27, 2019

Hugo >= 0.50 (including master HEAD as of today) exits before finishing building a website when getJSON fails to get a resource.

This problem was earlier filed as Issue #5076 "getJSON etc. should log ERROR but return nil in failure situations" and was fixed in 0.49, but perhaps the "greatly improved error messages shown in browser" feature in 0.50 might have undone the fix in PR #5199.

@bep bep changed the title getJSON fetch failure aborts build in Hugo >= 0.50 (reprise of #5076) getJSON fetch failure should not abort build Jan 27, 2019

@anthonyfok

This comment has been minimized.

Copy link
Contributor Author

anthonyfok commented Jan 27, 2019

git bisect v0.50 v0.49 says that d1661b8 is the first bad commit. Investigation continues.

@bep

This comment has been minimized.

Copy link
Member

bep commented Jan 27, 2019

Not sure what finding how finding who/what broke it will help fixing it. Why not just fix it?

@anthonyfok

This comment has been minimized.

Copy link
Contributor Author

anthonyfok commented Jan 27, 2019

I am actually trying to fix it; I am just documenting the progress along the way by pasting the result of the last "git bisect" command, though probably the output of that command was too verbose. I'll edit my last message to remove the details and just keep the commit hash to keep track of it.

@anthonyfok

This comment has been minimized.

Copy link
Contributor Author

anthonyfok commented Jan 27, 2019

Trying to find clues from the messages shown by hugo -v...

Before:

ERROR 2019/01/27 16:16:23 Failed to get JSON resource https://api.example.com/product?name=foobar: Failed to retrieve remote file: Not Found
Total in 1234 ms
Error: Error building site: logged 1 error(s)

After:

Error: Error building site: failed to render pages: [en] page "Test Website": render of "home" failed: execute of template failed: template: index.html:24:13: executing "main" at <getJSON "https://api...>: error calling getJSON: failed to get getJSON resource "https://api.example.com/product?name=foobar": Failed to retrieve remote file: Not Found

@anthonyfok anthonyfok self-assigned this Jan 27, 2019

anthonyfok added a commit to anthonyfok/hugo that referenced this issue Jan 28, 2019

@anthonyfok

This comment has been minimized.

Copy link
Contributor Author

anthonyfok commented Jan 29, 2019

My first attempt at a fix is at PR #5648, though I am starting to think I tried to fix the problem at the wrong place, and at a cost too: The nice context information provided by _errors.Wrapf() (from pkg/errors) is lost. So, simply replacing with _errors.Wrapf() with ns.deps.Log.ERROR.Printf() reverting to the pre-0.50 behaviour of no error context isn't ideal.

I am thinking that there should be a way to distinguish between fatal and non-fatal errors, maybe with the non-fatal ones marked with a "[non-fatal]" suffix in the error string so it can be checked later. (I have just barely started looking at the error handling code, so what I just said may be utter nonsense, my apologies.) Unfortunately, I won't have time to look at this issue again in this week or the next, hence this note in case anyone else (or maybe the future "me") wants to pick it up.

@anthonyfok anthonyfok removed their assignment Jan 29, 2019

@bep bep added Bug and removed NeedsInvestigation labels Jan 30, 2019

@bep bep added this to the v0.53.1 milestone Jan 30, 2019

@bep bep closed this in 6a2bfcb Feb 1, 2019

bep added a commit that referenced this issue Feb 1, 2019

@bep bep modified the milestones: v0.53.1, v0.54 Feb 1, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment