The contribution row is saved as part of the job, which happens (long) after the initial validation. For the same reason, the same edit can be associated with different events, if the requests are sent at the same time. We don't have a mechanism to allow inserting (sort of) a placeholder row, so we can't be entirely accurate in the validation. However, it's still possible to resolve or at least mitigate the issue by:

• Adding a locking system via object cache to register write intentions when a job is enqueued, and checking that first when validating a contribution
• Deduplicating jobs for the same revision (should be unnecessary when object cache locking is available, but there should never be duplicates anyway)
• Adding a unique index on the relevant DB columns (as a last safety net)

No hits in codesearch: https://codesearch.wmcloud.org/search/?q=CampaignEventsEnableEventGoals&files=&excludeFiles=&repos=

In T411681#11815856, @cmelo wrote:

• Given this approach, the ce_event_contributions field will use a default value of 0.
• A NULL default is not required.

In T421147#11810517, @A_smart_kitten wrote:

Is this reoccuring (or e.g. did it never stop occurring, at least for operations/mediawiki-config in the 'Everything' group)?

Config change scheduled for tomorrow 2026-04-14 13:00 UTC.

Thanks, makes sense! This is now ready for review then.

(I forgot to write it here, but I did look briefly into this and couldn't reproduce locally. Nonetheless, in the relevant code path we set $rawTZ from the WebRequest directly, so it can in principle be null I suppose. In that case we don't need to run most of the logic in getTimezone.)

Actually not quite the same, because while in the other task the alias was a simple coalesce, here it's actually an aggregate, so it can't be used in WHERE (which happens when paginating) and needs to be in HAVING instead. So, first of all we hit T308694: Sorting in TablePager doesn't work for aggregates. Maybe we should finally fix that, as it would also let us simplify the code for MyEvents pagination. I have implemented a simple workaround locally by overriding getOffsetCondsAndSortOptions, but it wouldn't pass on postgres as noted in T308694. Also, this table is larger and I don't know if the subquery approach would work well here, performance-wise. Then, even after we fix that, we'd hit T315465: Allow subclasses of IndexPager to process the offsets from the querystring before using them to build SQL: aggregates are integers, but the Pager logic tries to compare them with strings from the URL, which doesn't work in SQLite. That one should be relatively simpler to fix, but it needs a core change.

This is the same issue as T416569: those names are actually aliases, so they can't be used in WHERE in MySQL. There is a similar error in SQLite:

In T181024#11794979, @Xover wrote:

In T181024#11794399, @Daimona wrote:

… My current reading of this task … is that indeed, adding new functions should be safe. …

Ah, good. That means if someone is willing to pick up the task and/or your old patch there's no obvious blocker to getting it done. The status quo ante suggested that maybe there was.

Note that the AC below talk about "active events", but strictly speaking, that would be "events that are currently tracking contributions", not just "active". At any rate, the intent is obvious.

In T421749#11793090, @Lucas_Werkmeister_WMDE wrote:

Are there any potential issues between the “specialness” of the Incubator and CampaignEvents? E.g. would there be events like Event:Wp/grc/something for the Ancient Greek Wikipedia, and should they be handled / displayed in a custom way?

In T181024#11792332, @Xover wrote:

In T181024#6647194, @Daimona wrote:

While I'd love to implement this change, this is almost impossible due to current usage.

@Daimona It's not clear from the history of this task (or the patch) why it is "almost impossible due to current usage". As I read it the plan was to introduce new array-specific functions and new variables with explicit string semantics (so there's something to migrate to, long term), both of which are syntactically entirely safe. Any chance you could document here what led to that conclusion so that it becomes possible for someone to pick it up at some point?

Right, I forgot to mention two related tasks: T385342: [EPIC] Expand Event Registration to Support Project + Program Structure, T368331: Investigation: How do we define WikiProjects within the CampaignEvents extension?. I'm not sure where exactly we'd want to go in the direction of "reworking" WikiProjects, as the details of that were out of scope here, but there's definitely lots to explore in the area!

In T420250#11783861, @cmelo wrote:

In this investigation I created PoC that can be tested here, I focused on validating the basic flow for defining and using an event’s article worklist.

Boldly UBNing, as this affects the ability to see what's wrong with a patch (sure, local tests etc etc but that's not always straightforward)

For --analyze-twice specifically, things got better thanks to upstream change https://github.com/phan/phan/pull/5495, which changed the first pass of --analyze-twice so that it doesn't actually emit any issues. I'm going to upgrade to phan >= 6.0.3 to get this fix.

In T421993#11782550, @M0tty wrote:

The event https://dcwwiki.org/index.php?curid=1154 link to an .ics file that I used to save the event to my calendar. The problem is probably there? I thought it was generated by the event extension but maybe not??

More than 0 vs null, I think my question would be: what do we do with existing events? The three options being:

• Treat them as not having a reference delta defined (so, not shown in the UI, not included in reports, etc)
  • Pros: clear distinction.
  • Cons: special-casing that will remain around "forever"
• Treat them as having a reference delta of 0 (regardless of the real delta)
  • Pros: trivial implementation
  • Cons: inaccurate data
• Retroactively compute a reference delta for them
  • Pros: no special-casing; accurate data
  • Cons: more work than the other two

There is one big, important theme that everything here revolves around: we do not have any way to represent WikiProjects in software. A WikiProject is currently just an abstract concept. Its current on-wiki representation is a normal page, with no reliable and site-independent way of telling if a given page represents a WikiProject. And even then, there is no (machine-readable) metadata attached to them; most notably, there is no machine-readable information on their topic. For T368329: [EPIC] Collaboration List MVP, we did a very naive implementation that uses WDQS (which, as a reminder, does not make great operational guarantees) to get a list of WikiProjects. This was enough given the use case, but as we discussed back then, further work in this area would most likely require implementing proper abstractions for WikiProjects. I raised basically the same point in T390894: Investigation: How can we add improvements to the Communities tab? roughly 1 year ago, and those still apply to this investigation.

Thanks for sharing. As we briefly discussed, I agree that if batch lookup isn't possible, then we should not pursue this. Unless support for that could be added to liftwing in a relatively short time, but even then I guess there might be performance concerns (e.g., if a batch lookup of N entries would still be as slow as N individual lookups due to the backend).

Events do take timezones into account, there's a good chunk of logic to deal with that precisely because of how important it is for event participation. Of course, this requires event organizers to be mindful of the timezone they're using: for example, UTC is rarely a good choice, as event tend to be pinned to the time in a certain country. Using the example you provided, and retrieving event info via the API, we see that the event time is 2026-03-29 22:30:00 Asia/Kolkata, so that seems correct. I don't know what your timezone is, but for the purpose of explaining I'll use my own central european timezone. While it is true that DST rules differ between indian time and european time (in that, as you mentioned, indian time has no DST at all), this is correctly taken into account when showing the event time. To confirm, I created two events:

• https://test.wikipedia.org/wiki/Event:T421993-1 has a start time of 12:00 Asia/Kolkata on April 2nd (while Europe is in summer time)
• https://test.wikipedia.org/wiki/Event:T421993-2 has a start time of 12:00 Asia/Kolkata on November 15th (while Europe is in winter time)

Even if no longer worked on as part of Outreachy, this remains a valid feature request, hence reopening and adjusting.

Also, on the topic of this being potentially very annoying: maybe could be mitigated by using something other than the dialog. Something that doesn't fully steal focus (e.g. similar to bubble notifications but larger)

(BTW, somewhat related task: T420009: See if it's possible to run PHPUnit tests without `stderr=true` and without `ob_start`. That would've prevented this issue and other incompatibilities)

Made a prototype for this, see patch above. Testable on patchdemo: https://f3ca0c36f2.catalyst.wmcloud.org/wiki/Event:T419603 (just edit a random page)

Added Card to the list.

Copying from WMF slack:

In T413396#11709146, @ifried wrote:

Yeah, error seems excessive. Warning (or maybe notice?) is probably better. But we can wait until @JFernandez-WMF is back next week to ask her, in case there are other general design guidelines or best practices that we're unaware of.

Hmmm I can't exclude it, but I don't immediately see how. The line that adds skins has been there for a few years, it's not new. AIUI, the way it works shouldn't have changed recently. Is it possible we've always had vector in the coverage report for core?

Scheduled for tomorrow, 2026-03-23 14:00 UTC.

Scheduled for tomorrow, 2026-03-23 14:00 UTC.

Ah, I see. You are editing using VE I assume. We aren't loading goal data from the client side. I'll make a patch.

In T419731#11737895, @MHorsey-WMF wrote:

Testing is inconsistent for me, this doesn't seem to show up a lot of the time on my local build, am I missing something @Daimona / @cmelo

We should get this by default with the next phan upgrade, but keeping this task open as a reminder until then.

Note: I had to revert the workaround on itwiki. Section collapsing was broken on mobile: clicking on an open section header only hid the edit icon, not the actual section. The bug was not reproducible in safemode, hence leading me to that override. I am not familiar with the section collapsing code, but one thing I did notice is that even though the code clears the mfTempClickHandler, by the time that happens, the function has already been registered as a click handler. So, its original implementation would still be executed upon clicking. Maybe there was a better workaround, but given it's saturday morning and this task has been resolved, I've just removed the code without looking further; and sections are now working again.