Randomly getting outdated view.state.values while updating modals with response_action: update
The problem is that I'm randomly getting outdated view.state.values while updating modals with response_action: update. I've attached logs of view object, where you can see, that even block_id: 'answer_view100' when user submits modal — I'm getting outdated state values, from the two screens before: { values: { answer_view98: [Object] } }
For my task I'm updating one modal from 10 to 20 times, each update contains different input blocks. After each submission I'm collecting data and updating the view with next input block. block_id and action_id are uniq for each user session (but not uniq across whole app).
That's how I'm updating view:
const ackData = {
response_action: 'update',
view: modalView
};
await ack(ackData);
My main question: Why it could happen? Please point me in some direction. Maybe I'm doing something wrong.
I haven't tried to switch to views.update yet, due to lack of time.
package version: 2.1.1
node version: v13.11.0
OS version(s): Ubuntu 16.04.5 LTS (GNU/Linux 4.4.0-151-generic x86_64)
Sadly I'm not figured out exact steps. But such staff usually happening in rush hours, when 100-200 people simultaneously are using app. And with ~10% of that group of people, for majority everything is working fine.
I'm expecting to get view.state.values with actual data every time, I use it.
Sometimes I'm getting view.state.values with outdated data.
This is console log of the view that I'm getting when user submit modal.
{
id: 'V01AKKN7Y02',
team_id: 'T018PBTQPRD',
type: 'modal',
blocks: [
{ type: 'header', block_id: 'mg=Q6', text: [Object] },
{ type: 'section', block_id: 'dBs', text: [Object] },
{ type: 'divider', block_id: 'HkT0' },
{ type: 'header', block_id: 'v/WSm', text: [Object] },
{ type: 'section', block_id: 'OXlae', text: [Object] },
{ type: 'section', block_id: 'sM0', text: [Object] },
{ type: 'section', block_id: 'Ozoq1', text: [Object] },
{ type: 'section', block_id: 'F2Wp', text: [Object] },
{
type: 'input',
block_id: 'answer_view100',
label: [Object],
optional: false,
element: [Object]
}
],
private_metadata: '{"actionID": 44, "submitterID": 319, "testID": 10030, "questionID": 100}',
callback_id: 'NEXT_QUESTION',
state: { values: { answer_view98: [Object] } },
hash: '1599946164.CIXMSAQG',
title: { type: 'plain_text', text: 'Тест', emoji: true },
clear_on_close: false,
notify_on_close: true,
close: { type: 'plain_text', text: 'Later', emoji: true },
submit: { type: 'plain_text', text: 'Submit', emoji: true },
previous_view_id: null,
root_view_id: 'V01AKKN7Y02',
app_id: 'A018JCZ81DY',
external_id: '',
app_installed_team_id: 'T018PBTQPRD',
bot_id: 'B019U8E32SX'
}
Also there is a different odd behaviour of view.state, in one of the logs, I found whole history of view updates.
state: {
values: {
answer_view90: [Object],
answer_view89: [Object],
answer_view94: [Object],
answer_view92: [Object],
answer_view95: [Object],
answer_view93: [Object],
answer_view91: [Object]
}
callback_id: 'NEXT_QUESTION',
I have not reproduced this issue on my end yet but one thing I can suggest at this point is to use a unique callback_id for each question. When you update a modal, you can change the callback_id at any time. Going with callback_id: 'question_97',, callback_id: 'question_98',, and so on may help for your use case.
Thanks, I'll try it till the end of the week, and tell what happen
So, I tried to make callback_id unique (now it includes user_id and timestamp), but it didn't help. And I'm still getting outdated data (basically it means, that I'm loosing user input for some reason).
Still not sure how to reproduce it, since out of 100 users only 3-5 catching this behaviour.
{
id: 'V01BDRCA081',
team_id: 'T018PBTQPRD',
type: 'modal',
blocks: [
{ type: 'header', block_id: 'v=m7e', text: [Object] },
{ type: 'section', block_id: 'uF6', text: [Object] },
{ type: 'divider', block_id: 'Y4OD' },
{ type: 'header', block_id: '/kD7', text: [Object] },
{ type: 'section', block_id: 'bFzVB', text: [Object] },
{ type: 'section', block_id: 'rd6n', text: [Object] },
{ type: 'section', block_id: 'Y5b', text: [Object] },
{ type: 'section', block_id: 'LTFh', text: [Object] },
{ type: 'section', block_id: 'm4Z', text: [Object] },
{ type: 'section', block_id: 'zXL', text: [Object] },
{
type: 'input',
block_id: 'answer_view134',
label: [Object],
optional: false,
element: [Object]
}
],
private_metadata: '{"actionID": 58, "submitterID": 570, "testID": 10034, "questionID": 134}',
callback_id: 'NEXT_QUESTION_134_U01A63DDDNV_1600587714005',
state: { values: { answer_view133: [Object] } },
hash: '1600587714.BsvgJIkj',
title: { type: 'plain_text', text: 'Тест', emoji: true },
clear_on_close: false,
notify_on_close: true,
close: { type: 'plain_text', text: 'Пройти позже', emoji: true },
submit: { type: 'plain_text', text: 'Отправить', emoji: true },
previous_view_id: null,
root_view_id: 'V01BDRCA081',
app_id: 'A018JCZ81DY',
external_id: '',
app_installed_team_id: 'T018PBTQPRD',
bot_id: 'B019U8E32SX'
}
Still no luck catching this one. I've updated block_id to be unique across app, will see what happen
I got back to testing again.
Changing block_id to unique lowered error rate, but not to zero. So now all ids are unique:
Here is the case.
600 people completing assessment test via modal.
Test is presented by 12 different view, that are updated by response_action: 'update' each time.
Key difference between this views that input type is changing from static_select to multi_static_select
On 600 people error occurred 17 times.
6 times error occurred when update was on the same input type
11 times error occurred when update was on different input types (from static_select to multi_static_select or vice versa)
I tried to catch this error on demo space, but have no luck. It seems like it's occurs only under load.
@seratch any ideas what can I try next? I have 3 more next weeks to test under load (every 4 days)
@Wert1go I've escalated this issue to the server-side teams and now they are aware of it.
The server-side team is actively working on code improvements right now. They are expecting the changes will resolve the existing bugs including this issue. I cannot tell the exact release date of the changes yet, but we will update you accordingly.
Awesome! Thanks