andk
PAUSE will sometimes drop co-maint(s) when a co-maint does a release
The distribution Lab-Measurement has a lot of packages, all of which have SCHROEER with first-come.
On 2021-05-30, AKHUETTEL had co-maint on all packages.
AKHUETTEL released Lab-Measurement-3.751.tar.gz on 2021-05-31, and was told that he didn't have an indexing permission on Lab::Instrument::LabViewHeater, and when I check it, sure enough he doesn't have co-maint.
It seems likely this was dropped by the indexer :-(
I've added back the co-maint and will force a re-indexing to see what happens this time ...
Is this the same problem as #348 (which I was fairly sure had been fixed – we haven't seen that problem since the "fix" (PR#365) was deployed).
AKHUETTEL's comaint on Lab::Instrument::LabViewHeater wasn't lost on reindexing.
@andk is anything done differently on a reindex as opposed to the original indexing attempt when he uploaded?
On Sun, 06 Jun 2021 15:31:12 -0700, Neil Bowers @.***> said:
nb> The distribution Lab-Measurement has a lot of packages, all of which nb> have SCHROEER with first-come.
nb> On 2021-05-30, AKHUETTEL had co-maint on all packages.
I can confirm this.
nb> AKHUETTEL released Lab-Measurement-3.751.tar.gz on 2021-05-31, and was nb> told that he didn't have an indexing permission on nb> Lab::Instrument::LabViewHeater, and when I check it, sure enough he nb> doesn't have co-maint.
According to the git repo for 06perms.txt, the comaint-permission was removed between Mon May 31 22:17:23 2021 +0000 and Mon May 31 22:41:28 2021 +0000, which is the same interval during which the first indexer run happened. FYI, this was the commit: https://github.com/batchpause/PAUSE-git/commit/0b4d1832a8b71b956e1012c3f4d49261026e0971
You can see there that LabViewHeater was indexed in 02packages.details.txt was was lost from 06perms.txt.
nb> It seems likely this was dropped by the indexer :-(
I agree.
nb> I've added back the co-maint and will force a re-indexing to see what nb> happens this time ...
On Sun, 06 Jun 2021 15:35:28 -0700, Neil Bowers @.***> said:
nb> Is this the same problem as #372 (which I was fairly sure had been nb> fixed – we haven't seen that problem since the "fix" was deployed).
Nono, this new ticket here is the number 372. I think you mean 364 and 348 respectively, right? But those were about losing first-come, not about losing comaint, right? Was there another one with losing comaint?
On Mon, 07 Jun 2021 00:03:54 -0700, Neil Bowers @.***> said:
nb> AKHUETTEL's comaint on Lab::Instrument::LabViewHeater wasn't lost on nb> reindexing.
Darn it, this will be even more difficult to track when it is not easily reproducable.
nb> @andk is anything done differently on a reindex as opposed to the nb> original indexing attempt when he uploaded?
Of course are there some things different. Because the first upload was not a noop, it did not index nothing, it indexed what it told to have indexed. So when you re-index, you have some figures different in the database.
-- andreas
But those were about losing first-come, not about losing comaint, right?
Some of the comments in #348 refer to co-maints being lost, but I suspect there were really two bugs at that point, and #364 only fixed one of them.
AKHUETTEL has done all of the releases (I think the dist was previously called something else), and the affected package has been in the last dozen or more releases at least.
SCHROEER had (and still has) an entry in both perms and primeur, which suggests it's not related to the problem that was fixed in #364.
PLICEASE had co-maint the two packages in Devel-ebug-HTTP:
Devel::ebug::HTTP,AWWAIID,c
Devel::ebug::HTTP,LBROCARD,f
Devel::ebug::HTTP,PLICEASE,c
Devel::ebug::HTTP::View::TT,AWWAIID,c
Devel::ebug::HTTP::View::TT,LBROCARD,f
Devel::ebug::HTTP::View::TT,PLICEASE,c
Today (2021-06-28) he released P/PL/PLICEASE/Devel-ebug-HTTP-0.33.tar.gz, after which the index has:
Devel::ebug::HTTP 0.33 P/PL/PLICEASE/Devel-ebug-HTTP-0.33.tar.gz
Devel::ebug::HTTP::View::TT 0.33 P/PL/PLICEASE/Devel-ebug-HTTP-0.33.tar.gz
But 06perms now has:
Devel::ebug::HTTP,LBROCARD,f
Devel::ebug::HTTP::View::TT,AWWAIID,c
Devel::ebug::HTTP::View::TT,LBROCARD,f
Devel::ebug::HTTP::View::TT,PLICEASE,c
So the indexer recognised that he had co-maint on both packages, updated both packages in the index to refer to his release, but then dropped both of the co-maints on the lead module.
I'll put the co-maints back on the lead module and force a re-indexing. Guessing that as with the previous case, the permissions won't be dropped.
When the indexing was processing PLICEASE's release, it hit the transaction timeout. Here's the relevant part of the email that he got from PAUSE:
Status: Database error
======================
module : Devel::ebug::HTTP::View::TT
version: undef
in file: Devel-ebug-HTTP-0.33/lib/Devel/ebug/HTTP/View/TT.pm
status : The PAUSE indexer could not store the indexing result in
the DB due the following error: C< Lock wait timeout
exceeded; try restarting transaction >. Please report the
case to the PAUSE admins at [email protected].
Status: Permission missing
==========================
module : Devel::ebug::HTTP
version: 0.33
in file: Devel-ebug-HTTP-0.33/lib/Devel/ebug/HTTP.pm
status : Not indexed because permission missing. Current registered
primary maintainer is LBROCARD. Hint: you can always find
the legitimate maintainer(s) on PAUSE under "View
Permissions".
If I remember rightly, the indexer checks they have permissions and if so, it updates the relevant entries. Then it calls canonicalize_module_casing(), which deletes permissions and adds them back. So if the timeout happened at the right time, it would drop the co-maints. This explains why his release was successfully indexed and then the permissions dropped. I'm confused as to why he got the message about the missing permission though, as for my theory to be right, the check for that succeeded.
The best fix is to restructure things to avoid the timeouts, but a more feasible "interim fix" might be to rewrite canonicalize_module_casing() so that it builds what it thinks the correct permissions are, and if what's in the database already matches, then do nothing. That would at least prevent most the cases we've seen.
This happened today (2023-05-15). Up to now, the only indexing permission on App::HTTPThis was:
App::HTTPThis,MELO,f
Dave Cross (@davorg) asked for co-maint, and MELO gave his permission for me to add Dave as co-maint. I did this in the usual way, and this resulted in the following permissions:
App::HTTPThis,DAVECROSS,c
App::HTTPThis,MELO,f
Dave then released App-HTTPThis-0.003.tar.gz which resulted in an indexing email from PAUSE which included:
module : App::HTTPThis
version: 0.003
in file: App-HTTPThis-0.003/lib/App/HTTPThis.pm
status : Not indexed because permission missing. Current registered
primary maintainer is MELO. Hint: you can always find the
legitimate maintainer(s) on PAUSE under "View
Permissions".
And now Dave's co-maint has gone from 06perms.txt.
I'm guessing this is related to the DB lock timeout issue. I'll give Dave co-maint again, and then re-index his latest release. You don't need to do anything Dave.