Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.The releases for http://drupal.org/project/button_style were already packaged, the release nodes exist, but they do not show up on the project page.
Also, when going to "Administer releases", the form is empty.
Not sure what went wrong there. Other releases for my other projects work just fine as always. So I guess there must be some internal id mismatch, stale process, or something like that.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 550888-3.package-check-supported-replication-delays.patch | 2.71 KB | dww |
Comments
Comment #1
dwwSounds like this could be a bug introduced by #539282: Denormalize release info a bit and store latest and recommended releases in {project_release_supported_versions}. {project_release_supported_versions} was empty for your project, which is why nothing showed up and the form on the "releases" subtab when you tried to edit was empty.
Can you tell me more about what happened here? This is a new project? You tagged and created all 4 releases at the same time? Did you do anything other than tag in CVS and create release nodes? Can you give me the timeline of what you did and what you saw after you did it?
I ran the function that's *supposed* to be invoked by the packaging script whenever it publishes a release node, and that got everything working on your project page. So, it seems like somehow that function isn't getting called when it should, or at the time it's called, things aren't yet published in the DB, or something. Maybe there's replication badness at work here.
Anyway, if you give me more info, maybe I can reproduce this locally or on d6.d.o, and hopefully track down the ultimate source of the trouble.
Thanks,
-Derek
Comment #2
sunSure! I don't think that I did anything abnormal. I just did it fast, and maybe that was the cause? ;)
Yes, this is an entirely new project. And yes, I thought I could do this quickly -- though definitely NOT in parallel or something like that; just fast, i.e. most of the following probably happened within 2 minutes.
My steps from scratch:
1) Created the new contributions/modules/button_style CVS directory
2) Committed my code in there
2a) Created the project node.
3) Branched that into DRUPAL-5
4) Tagged HEAD with DRUPAL-6--1-0
5) Tagged DRUPAL-5 with DRUPAL-5--1-0
[Following order my be important]
6) Created a new dev snapshot release node for 6.x-1.x pointing to HEAD
7) Created a new dev snapshot release node for 5.x-1.x pointing to DRUPAL-5
8) Created official release node for DRUPAL-6--1-0
9) Created official release node for DRUPAL-5--1-0
After that, and noticing first that nothing was there after a few minutes,
10) I saw that official releases were packaged properly, while dev snapshots were (of course) still queued
There were no error messages or anything that would have indicated that something went wrong. Otherwise, I would have stopped that process immediately.
Anything else? I'm trying to think hard. But I don't think there was more to it. Not sure whether the "I did it fast" (in the scope of minutes) really matters. But my first concern after not seeing the releases was: "Should I've had created the official releases first to make any dequeuing magic happy?"
I hope that helps at least a bit :)
Comment #3
dwwI can't actually prove the new title is true, but that's my best guess as to what's happening here. There have apparently been a lot of reports of this:
#552326: 0.1 release doesn't appear
#552430: Taxonomy Manager recommended version problems
...
All of this started after the recent d.o downtime where I upgraded the packaging script (to fix #184418: update(_status) results stale for up to 6 hours among other things). Included in there was what I thought was an optimization to remove duplicate calls to project_release_check_supported_versions(). However, it seems like those duplicate calls are actually necessary in the case of DB replication (which we have on d.o) since at the time when it's first called (during node_save() as we publish the release node), if we're talking to a replicated DB, the updates might not have propagated yet.
Pretty sure this patch is going to solve it, and it certainly doesn't make things any worse with my local testing, but it's really hard to actually replicate the problem except on d.o. I think I'm just going to deploy it and see if new reports of problems in this area stop coming in and call that success. ;)
Comment #4
dwwFYI, here's the change from #184418: update(_status) results stale for up to 6 hours that I think is causing us the new trouble:
http://drupal.org/cvs?commit=249242
http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/project/rel...
Comment #5
sunI don't know the innards, but it looks like your patch is a straight revert to the old code + some minor improvements. So I'd say: just go ahead - because it seems that there are indeed a lot more releases affected (for example, admin_menu's new alpha3 is still not reported in Update (Status), probably the same as one of the issues you referenced above). :)
Comment #6
sunThough I'm a bit confused, but you can happily ignore this follow-up:
- The new code talks about release history XML files, and invokes PHP CLI to generate those through another script. It processes a single $project_nid.
- The old/reverted code talks about supported/recommended project release settings. It processes each major version for each core compatibility for each project.
Different functionality?
Comment #7
dww@sun: Yes, different functionality.
project_release_check_supported_versions() needs project nid, core compatibility tid, and major version int, and keeps the {project_release_supported_versions} table in sync with reality. The fact your project didn't have any rows in this table is why the node/N/edit/releases UI for selecting supported branches and displaying -dev snapshots or not was missing on your project the other day.
project-release-create-history.php CLI is what generates the XML release history files. It just takes a project nid command-line argument and limits itself to that one project. Since we have files for both all releases and separate files for each version of core, to regenerate the history you already have to query for everything, so you might as well just regenerate the whole history for a project, instead of trying to restrict it to specific versions of core.
Make sense?
Comment #8
dwwUpon closer inspection, the real bug was here: #540074-4: Denormalize release API compatibility tid into {project_release_nodes}. However, I don't think this patch is going to hurt anything, so I'm tempted to leave it installed and commit it anyway. It'll make for some extra queries at the end of each packaging run, but it could potentially save us trouble from various replication edge cases down the road...
Comment #9
dwwEven though the real bug was elsewhere, this patch won't hurt, and might prevent problems in the future. So, I committed to HEAD, synced the latest project code into SVN, and deployed rev 1610 on d.o.
Comment #10
sunThanks! :)
Comment #11
joachim commentedI can confirm my 0.1 release is showing up now. Thanks!