cannot unmarshal object into Go struct field InteractionCallback.state of type string

[sambaiz]

Following error occurred when handling block_actions callback.

cannot unmarshal object into Go struct field InteractionCallback.state of type string

The field is documented as dictionary of objects but the field of struct is string.

https://api.slack.com/reference/interaction-payloads/block-actions#reference-interactive-components-payloads__fields

state.values or view.state.values | A dictionary of objects keyed with the block_ids of all blocks containing stateful, interactive components .

{
    "type": "block_actions",
    ...
    "state": {
        "values": {
            "<block_id>": {
                "<action_id>": {
                    "type": "static_select",
                    "selected_option": {
                        "text": {
                            "type": "plain_text",
                            "text": "foo",
                            "emoji": true
                        },
                        "value": "foo"
                    }
                }
            }
        }
    },
    ...
}

[kanata2]

Thank you for reporting.
Umm, my old app works correctly for now 🤔
The behavior may be different between existing apps and new one.
Can you share some reproducible code if you'd like?

[MathiasGr]

Hi there - Im seeing the same error in prod this morning - I think Slack deployed a schema change within the last 24-48h that is breaking unmarshalling.

This is happening on interaction callbacks (webhooks), the payload has changed and thus breaks Golang's quite strict JSON unmarshalling.

cannot unmarshal object into Go struct field InteractionCallback.state of type string"

EDIT:
checked broken payload and it looks exactly like the one mentioned above, and the culprit is there:

slack/dialog.go

Line 57 in 17a0fae

State string `json:"state,omitempty"`

State is defined as string.

I'm willing to push a fix, but such nested values are a real pain in Go. You need to decide whether it's worth the effort. For everyone looking for a quick fix, you just have to remove that line so that go doesn't try to unmarshal the State field.

EDIT 2:
Here's a fix that doesn't touch dependencies, by removing the state field before unmarshalling:

	fixMap := make(map[string]json.RawMessage)
	if err := json.Unmarshal(body, &fixMap); err != nil {
		// handle error
	}

	delete(fixMap, "state")
	fixedJSON, err := json.Marshal(fixMap)
	if err != nil {
		// handle err
	}

	// unmarshal fixedJSON into slack.InteractionCallback

[kanata2]

I may have figured out this problem.
Perhaps you receive string state if you submit from Dialogs and
you receive dictionary array state if you submit from Block Kit like HomeTab.

UPDATED: I'm sorry. I'm wrong about the type of interactions in Slack. Please ignore this comment X)

[plilius]

Happening in prod for us as well. Can confirm that issue seems to be happening with block kit.
Do you think this might be what is causing issues? https://api.slack.com/changelog/2020-09-full-state-on-view-submisson-and-block-actions

[prgres]

Same issue for me, which force me to delete state from the payload as a workaround

[kanata2]

Thanks.
Let me give some consideration to how to fix.

[clockworkcoding]

I'm seeing this error for mobile users, but desktop users are currently unaffected

[prgres]

I'm seeing this error for mobile users, but desktop users are currently unaffected

The issue occurs on desktop as well.

[mzduke]

Just my 2 cents.

This is definitely related to that update: https://api.slack.com/changelog/2020-09-full-state-on-view-submisson-and-block-actions
It was not supposed to be a breaking change but it is for Go apps (at least based on that library).

The source of the problem that the library is using InteractionCallback struct for multiple types of interactive submissions (e.g. view_submission or block_actions) and dialog_submission.
It looks like the Slack platform team forgot (or ignored) that dialog_submission already contains the state property which is a string while other types of submissions contain the new state property which is a nested structure.

The possible solution from my point of view is to write a dynamic JSON unmarshaling and based on the type of submission treat state either as a string or as a struct and put into two separate fields (e.g. stateValues for struct and keep state for string case).

Suggested earlier workaround with deletion of state will help to avoid errors, but will brake Dialogs which uses state.
And an alternative option is to abandon the support of legacy Dialogs (means remove support of string-typed state at all).

[alyosha]

thanks @kanata2 for jumping on this, would be great if we could get a fix prioritized 🙏

[kanata2]

I'll merge #820 to fix this issue.
If the problem recurs, please let me know again.

[kanata2]

released v0.7.1