Editing community leads to a 400 error message

[ori-near]

Problem

Trying to edit various aspects of the community leads to a 400 error message.

Repro Steps

1. Admin user goes to DevHub Hacks community and clicks Configure Community
2. Click Edit Community Information, and change the tags from hacks, hackbox to just hackbox. Or try to update the Telegram URL.
3. Click Submit
4. Click Save
5. Click Confirm Transaction
6. See error message

Desired Behavior

User is able to submit the changes without getting an error message.

[elliotBraem]

Picking this up

[elliotBraem]

I've been unable to reproduce this in the devhub-test group via Google Chrome or Brave. Is this Safari?

I've been able to :

1) modify the Telegram 2) modify Tab names 3) add and remove tags

Will attempt on Safari now.

Then, can I have admin access to attempt to configure the Hacks group?

Edit:

Updates also work on Safari. Not sure what the issue is.

Can I have admin access to attempt to configure the Hacks group?

[ori-near]

Hi @elliotBraem – yes was using Safari. Gave you admin access.

[ori-near]

Hi @elliotBraem I just reproduced this in Chrome too with a different account.

[elliotBraem]

I've been able to reproduce and only for this community: DevHub Hacks

https://github.com/near/neardevhub-widgets/assets/16282460/32046d38-65c0-47f0-951c-de15c490bded

There is something wrong with the request to wallet.near.org.

It worked when I logged in via Here wallet and completed the transaction that way.

NEAR Wallet is being depreciated, but this may be something to keep an eye on.

@ori-near

I've changed tag to hackbox.

Now, doing more changes to the community breaks in both the NEAR Wallet and through Here wallet.

[ori-near]

Hi @elliotBraem – I saw you tagged me here. Was it just an FYI, or did you need any input?

By the way, I continue running into additional issues. For example, trying to remove moderators from a specific community page (e.g. Zero Knowledge) leads to the same error message.

[ori-near]

Hi @elliotBraem – just wanted to follow up here.

[elliotBraem]

@frol @petersalomonsen @ailisp @itexpert120 @Megha-Dev-19

I'd like to bother you all for some thoughts & feedback on this specific issue :)

It seems that there is something wrong with the request that gets sent to the wallets when editing specific communities. If you look at the video above: the community data looks normal and good JSON, but when we submit, it says malformed.

The contract is not panicking, the request is malformed before the wallet can present the transaction.

It's especially interesting because I have been able to approve one these "malformed" transactions with different wallets -- I approved the first one with Here wallet, but then it broke after. It currently seems specific to the DevHub Hacks community, but @ori-near reports others may be impacted too.

Why might this happen?

1. Have any of you seen this happen before?
2. Are there best practices we are not following when it comes to adding/updating contract data?
3. How can an inconsistency like this occur? Is it related to data migrations, contract versions?

During the revamp, we migrated the communities from the old structure to the new structure w/ Addons where Ori and Maxwell used this Community Migration Button that I had made, and this may be relevant, but I'm not sure how. It did not modify the existing data, it only created add-ons from it -- nor have I experienced any issues updating the addons directly, even in the DevHub Hacks community.

How can we fix this?

We have some pieces of the community struct that are no longer used due to the Addons, could we fix this by cleaning up the struct and migrating? Or is the corruption deeper than that?

pub struct Community {
    pub admins: Vec<AccountId>,
    pub handle: CommunityHandle,
    pub name: String,
    pub tag: String,
    pub description: String,
    pub logo_url: String,
    pub banner_url: String,
    pub bio_markdown: Option<String>,
    pub github_handle: Option<String>,
    pub telegram_handle: Vec<String>,
    pub twitter_handle: Option<String>,
    pub website_url: Option<String>,
    /// JSON string of github board configuration
    pub github: Option<String>,
    /// JSON string of kanban board configuration
    pub board: Option<String>,
    pub wiki1: Option<WikiPage>,
    pub wiki2: Option<WikiPage>,
    pub features: CommunityFeatureFlags,
    pub addons: Vec<CommunityAddOn>,
}

From the above, we can remove "github", "board", "wiki1", "wiki2", "features" because of Addons-- and I also think it'd be cleaner if we reflected the social contract metadata standard more:

pub struct Community {
    pub admins: Vec<AccountId>,
    pub handle: CommunityHandle,
    pub metadata: CommunityMetadata,
    pub addons: Vec<CommunityAddOn>,
}

pub struct CommunityMetadata {
    pub name: String,
    pub description: String,
    pub image: String, 
    pub backgroundImage: String,
    pub tags: Vec<String>,
}

Anyone have thoughts/feedback on why this issue is arising and solutions moving forward?

[petersalomonsen]

@elliotBraem I've seen earlier when working on my music tools. If trying to confirm a large transaction through the wallet, it will fail, since it's too large for the URL redirect to the wallet. Could it be the same?

In the music tool the solution was to not sign the transaction through the wallet, but use a local function access key, which is what I'm working on, and which works right here https://github.com/NearSocial/VM/pull/156

Can you try the same from the preview environment here?

https://psalomobos.near.page/devhub.near/widget/app

Make sure to have saved a function access key before attempting the transaction above, so that it does not go via the wallet for confirmation @elliotBraem @ori-near

[elliotBraem]

Yes the reasoning seems the same -- we update the entire community at a time (including all of the addons and their data) -- this is a pretty big payload.

And yes! Creating a local function access key to sign the transactions in your preview environment worked excellently!

However, although this works and we could wait for the access key change to get in, I think there are some contract changes we should do to fix this, too:

We need the payload in these function calls to be smaller. When updating a community, rather than pass the entire community at a time, we can split this into update_community_metadata, update_community_admins, and use the existing set_addons function. I have created two stories on the contract repo to suggest this: Community Metadata #75 and Addon Cleanup #74. This will involve changes to the front end as well.

[elliotBraem]

This is blocked until #137 is resolved or the contract changes are implemented.

Until then, any interactions that typically encounter this issue can be resolved using :

https://psalomobos.near.page/devhub.near/widget/app

[Tguntenaar]

I will pick up the necessary contract changes now.

[frol]

@ori-near This is a bug of wallet.near.org as they don't allow big transaction to be signed. Use any other wallet to workaround it. Since wallet.near.org is getting deprecated soon, I suggest we close this issue and just ask users to use a different wallet.

I reviewed the current implementation, and there is no simple way to avoid this behavior. We already update the data in chunks, but Wiki pages require you to set quite a sizable chunk of data on chain.

[frol]

It seems that we still can hit the URL limit even with MNW. We need to cut the community updates in pieces and it will be partially done as part of https://github.com/near/neardevhub-widgets/issues/540#issuecomment-1854590516. This problem is only hit with quite beefy communities. We may need to consider how to store the Wiki content separately from the add-on configuration, so it does not blow up the transaction size when completely not necessary.

[Tguntenaar]

Doesn't the content on the wiki itself reach the limit?

If we treat the wiki differently from the other addons, it implies that community addon builders are limited in what they can build.

Transferring it to a different structure would just shift the problem; So to keep the wiki as an addon, I think the only solution is to divide the parameters into multiple parts and make multiple update calls if the content is above a certain size.

@frol @elliotBraem let me know what you think

[frol]

If we treat the wiki differently from the other addons, it implies that community addon builders are limited in what they can build.

@Tguntenaar I don't suggest to treat Wiki addon any differently, but implement it in a different way, so instead of inlining the content as a parameter, inline a reference to the content, e.g. use SocialDB key path as a parameter instead of markdown text.

[Tguntenaar]

Thanks for the feedback, so we will have to wait for 540 first.

[elliotBraem]

This is still waiting on #488

[elliotBraem]

Since VM PR has been merged to develop branch, we are only waiting for the VM to be updated and gateways to follow. Then this issue should be resolved.

[ori-near]

@ailisp / @frol – doing a backlog grooming. I see this ticket has been in blocked for a while. I assume we can close it?

[ailisp]

@ori-near I can't reproduce the problem, editing devhub hacks community work for me. From the conversation above, it is a near wallet error which is now replaced by mynearwallet. @frol mentioned "we still can hit the URL limit even with MNW", but I don't see it happens when editing this community, and this community's wiki. Thanks to @elliotBraem and @Tguntenaar 's work the wiki has been made as addon, so more wikis won't make this a problem as well. We can close this issue.