fix: don't throw ipfs errors, use defaults

[wgwz]

Closes: #146

Testing:

1. create a proposal with an invalid ipfs url for a group policy address i.e.

➜  ~ cat proposal.json 
{
  "@type": "/cosmos.group.v1.MsgSubmitProposal",
  "group_policy_address": "regen1mqevjln5hxv3qgd3c4m5zjeeand5hkc7r33ty82fjukw9shxjh6s6d4umv",
  "proposers": ["regen1fhjpuh6qh6kjsedtmfxrayvmzlknkzde92ky2j"],
  "metadata": "ipfs://CID",
  "messages": [],
  "exec": "EXEC_UNSPECIFIED"
}

2. submit the proposal via cli i.e.

➜  ~ ~/go/bin/regen tx group submit-proposal proposal.json --keyring-backend test --chain-id test 

3. Go to the page for the group in the groups-ui, observe that the group page and proposal page loads successfully.

4. Checkout dev, repeat 1-3, observe the failure.

[netlify]

✅ Deploy Preview for groups-ui-storybook ready!

Name	Link
🔨 Latest commit	685652f
🔍 Latest deploy log	https://app.netlify.com/sites/groups-ui-storybook/deploys/6500dd8c8860110008d03e55
😎 Deploy Preview	https://deploy-preview-149--groups-ui-storybook.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for regen-groups-ui ready!

Name	Link
🔨 Latest commit	685652f
🔍 Latest deploy log	https://app.netlify.com/sites/regen-groups-ui/deploys/6500dd8c6f2a8f0008ed1c54
😎 Deploy Preview	https://deploy-preview-149--regen-groups-ui.netlify.app/
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[ryanchristo]

You can also test using the deploy preview connected to mainnet here.

Any ideas why the proposal is not showing up when we hit this error? I think we want to have a fallback in place and show the proposal. It looks like this solves the immediate issue though with the page not loading.

I'm ok with addressing the fallback separately if not a quick fix.

[wgwz]

@ryanchristo it was showing up for me when i tested locally, i’ll take a better look but it may just be a separate issue. i’m kind of confused by what’s showing in your logs, unless i’m mistaken i thought the new log statement i added would have shown up there.

oh you know what, maybe it was because i tested the metadata as precisely ipfs://CID whereas the metadata in the proposal Sam added might have had quote characters around it. i’ll look at more and see if that was it, and if so i’ll just do a fix here

[ryanchristo]

You should also be able to test locally with the proposal on mainnet: http://localhost:5173/6

[ryanchristo]

You should also be able to test locally with the proposal on mainnet: http://localhost:5173/6

Actually you would hit a CORS error if you did this with the production indexer so nvm.

[wgwz]

> Any ideas why the proposal is not showing up when we hit this error? I think we want to have a fallback in place and show the proposal. It looks like this solves the immediate issue though with the page not loading.

@ryanchristo i think the reason that proposal doesn't show up is because the deploy preview is not connected to the production indexer either, right? the groups-ui deploy previews are connected to the staging indexer only, unless i'm just totally misremembering stuff.

nevermind. that's not the case. duh

[wgwz]

Actually you would hit a CORS error if you did this with the production indexer so nvm.

we can disable CORS temporarily on the server, and that should make it work, and allow better debugging

[wgwz]

it looks like a possible explanation for why the proposals are not showing up here:
https://deploy-preview-149--regen-groups-ui.netlify.app/6
is a bug in the historical proposals fetching.
it looks like this group has two group policies.
TL;DR there may be a bug in the useGroupHistoricalProposals function in this case.
i'm not sure how well i tested this scenario.
it's possible that because one of the indexer API calls returns an empty result set, that we are using that.
for one of the policy addresses we find proposals and for the other policy we get the empty set.
you can see this in the network tab when you have the group page open, and requests filtered to "graphql":

Request/response for first policy:

Request/response for second policy:

it's fairly obvious that's a bug because we get some historical proposals, so those should be showing.
pretty sure this explains it

[ryanchristo]

tACK. Sounds like a separate issue. This pr looks good to me.

[wgwz]

Opened an issue for the missing proposals:
#150