grist-core: Issue: URL for published form throws an error
Function/Service
Forms
Issue
Updated to the latest version of grist today. It is running as a container in my self-hosted server. I tried the new forms functionality and created a form and published it. The link generated as part of the preview works fine, the data I key in gets saved in the appropriate table. However, when I try the link from the ‘Copy Link’ option in the form I get a page as shown in the screengrab.
Error message
There was an error: Unexpected token < in JSON at position 0.
Screenshot
About this issue
- Original URL
- State: open
- Created 5 months ago
- Comments: 15 (6 by maintainers)
The next sync to
main(slated for early next week) will include a fix. Will report here once it’s available.It also fixes the Fetch failed error we got. Much appreciated.
The sync of grist-saas code @georgegevoian mentioned happened this morning. The relevant change I think is this one: https://github.com/gristlabs/grist-core/commit/c6fd79ac1f08ab4146e3bca400325052b4ad257e
Maybe @georgegevoian can give more context. Sorry for how opaque this change was, we are slowly moving more development over to grist-core but it is still a work in progress.
It fixes the
Fetch failederror I got when running local kubernetes pods! 😃Though the problem is different from the
access deniederror we have on our production (but we will give it a try at least to check), and for which we need to diagnose.The
latestimage should now have the changes.It’s part of a broader refactor of forms, to more closely align with the other client-side Grist code. All forms API requests are now routed through DocApiForwarder, which should do a better job at building URLs that the home server can actually reach. I’m not sure if it’ll address all of the issues (e.g. the submission issue @StreamlinedStartup reported, which may be unrelated), but please give it a try and let us know how it fares.
@gdedrouas I also have encountered this issue in a local environment (in our production though we have a different issue). In our case, it’s because the hostname of public URL for the home server cannot be resolved behind the reverse proxy.
That’s something I meant to fix through this issue at first: https://github.com/gristlabs/grist-core/pull/864/files
It would mean that you would have to set a new env variable (at least in my case, it would solve my issue):
APP_HOME_INTERNAL_URL.But I was told that the guilty piece of code requiring that would probably be changed soon so this new env variable would not be necessary. So probably the PR I can close this PR @paulfitz?