This task has been migrated to GitLab.

This task has been migrated to GitLab.

We have a new one that went unnoticed until 19 days ago: b'superduper/super/sub/bye.txt' is not a valid directory entry name.

To force kafka compaction to run I've done the following:

This is now done, the objects are fixed in the production DB and kafka.

@vlorentz I'm running the following adaptation to your script:

Oh yeah, I was thinking of just removing the entire project, but your solution also works.

Holes are bad. And I just opened a diff to make the git loader apply the same transformation, as @olasd made the same comment: D8776

Do you actually want to keep these objects? This would be inconsistent with the fixed loader behavior that would just reject those objects, and not load the repository at all.

I tried to add a workaround in the backfiller, but it is incredibly hard to do properly, especially as entries as disordered, so raw_manifest needs to be fixed in two different ways.

This task has been migrated to GitLab.

This task has been migrated to GitLab.

Deployed both in staging and production [1]:

No more idle in transaction queries and corrupt_object still growing [1].
We can close this.

Scrubber got finally adapted so migration script is now ok [1]
Closing this.

We now have corrupt object being stored in the db:

11:26:40 swh-scrubber@db1:5432=> select count(*) from corrupt_object ;
+-------+
| count |
+-------+
| 59238 |
+-------+
(1 row)

And v0.0.6 tagged and deployed.

With [1] applied, the insert query got executed!

Stopping all services and letting run only 1 checker service.

Nothing bulged, same id process...
(Well, new ones appeared but old ones are still waiting for something)

We have plenty of processes stuck with "idle in transaction". According to [1], this means
"waiting for client inside a BEGIN block", so there might be issues in the scrubber code
[2]?

There seem to still exist staling queries [1] and nothing gets written to the db [2]:

Finally, after installing postgresql-client-11 and stopping scrubber services [1]:

It was still not ok as the upgrade tooling also expects the sql/upgrades/<final-version>.sql to exist and be packaged.
There was nothing there hence [1]

And now time to unstuck the debian build...

And now time to unstuck the debian build...

@vlorentz And now we got [1] to unstuck.

Well, i don't get it the apparent locking situation.
Services that do need to write to the db have the proper credentials for that.