I upgraded to Sentry 8.18 from an older version and the pages started loading to long:
The response is huge and most of the data is filled with something like {“status”: “complete”, “dateCompleted”: “2017-07-31T14:09:27.267Z”, “task”: 6, “data”: {}, “user”: null}
What can I do about this?
So I’m guessing this is the same issue? https://github.com/getsentry/sentry/issues/5893
Are you able to share the full payload? Since as far as we know, we haven’t seen any issue with this on sentry.io and nobody has complained there, so not sure what the issue would be.
Also, based on your screenshot, if that url is accurate, that should be a 404.
There are two endpoints here related to organizations. There’s organization list, which is sorta what you have here, but it’s missing a tailing slash. But without this trailing slash, it’ll be a 404. This organization list endpoint wouldn’t be spitting back this onboarding tasks either which is what you’ve shown pasted in here.
And an organization detail endpoint would include this information. But a single organization can only, in theory, have a max of 9 values here. So it seems unlikely that this could somehow expand into 20MB of data from only 9 items.
So getting access to the full payload here would be useful. Looking at a few of these samples from production data, verifies my assumptions. I’m not sure if there’s something else at play that is causing this behavior to be broken possibly for on-premise users.
Here is the (almost) full payload: https://drive.google.com/a/mindojo.com/file/d/0B5pHRinsaoHST1BSamt0OUJ1Tlk/view?usp=sharing
I removed teams and Organization name.
Ouch. So it sounds like something is wrong with your database. There’s no reason for there to be all of those duplicate things.
Can you paste the schema of your sentry_organizationonboardingtask table? Something like \d sentry_organizationonboardingtask. It sounds like you’re missing the index to make these values not infinitely grow in size. This should have come in with migration 0236.
new_sentry=# \d sentry_organizationonboardingtask
Table "public.sentry_organizationonboardingtask"
Column | Type | Modifiers
-----------------+--------------------------+--------------------------------------------------------------------------------
id | bigint | not null default nextval('sentry_organizationonboardingtask_id_seq'::regclass)
organization_id | bigint | not null
user_id | integer |
task | integer | not null
status | integer | not null
date_completed | timestamp with time zone | not null
project_id | bigint |
data | text | not null
Indexes:
"sentry_organizationonboardingtask_pkey" PRIMARY KEY, btree (id)
"sentry_organizationonboardingtask_organization_id" btree (organization_id)
"sentry_organizationonboardingtask_user_id" btree (user_id)
Check constraints:
"sentry_organizationonboardingtask_status_check" CHECK (status >= 0)
"sentry_organizationonboardingtask_task_check" CHECK (task >= 0)
Foreign-key constraints:
"organization_id_refs_id_2203c68b" FOREIGN KEY (organization_id) REFERENCES sentry_organization(id) DEFERRABLE INITIALLY DEFERRED
"user_id_refs_id_22c181a4" FOREIGN KEY (user_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED
Thank you for your help.
select * from south_migrationhistory;
...
244 | sentry | 0236_auto__add_organizationonboardingtask__add_unique_organizationonboardin | 2016-03-21 14:04:42.457109+00
...I think I remember having troubles with the migrations in March. I was fiddling with the database and failing upgrade. Looks this could have been the source of the trouble. Would you please help me to add the unique index?
What version of Postgres is this? This is definitely missing the UNIQUE index needed. But you have the table… so I’m real curious how this happened. We can truncate all the data and add the index manually if we need to.
This migration was added back in 2016 so nothing has changed since then, and the UNIQUE existed at the time of the table creation: https://github.com/getsentry/sentry/pull/2694
To manually create it, you’ll first need to truncate all the data in this table, since you have rows which violate this constraint in the first place. So the UNIQUE will fail to apply.
TRUNCATE sentry_organizationonboardingtask;
CREATE UNIQUE INDEX sentry_organizationonboar_organization_id_47e98e05cae29cf3_uniq ON sentry_organizationonboardingtask (organization_id, task);
This data is safe to delete, so there’s no real concern in data loss or anything.
This helped, Matt! Thank you!