# Repeating Event " going" gets not deleted anymore
**URL:** https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780
**Category:** Bug
**Tags:** events, fixed
**Created:** [November 12, 2024, 2:51pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780 "2024-11-12T14:51:56Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@anko127](https://meta.discourse.org/u/anko127)
#### Post date: [November 12, 2024, 2:51pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/1 "2024-11-12T14:51:57Z")
Hello,
when users click “going” for a weekly repeated event, normally their votes disappiered right after the event and you could always see the new votes for next week. Now they accumulate to a Long list.
I might have changed some configuration about the visibility of events but I do not find it to reset it.
Any Idea, thank you
Ann
---
### Author:  [@anko127](https://meta.discourse.org/u/anko127)
#### Post date: [November 22, 2024, 7:52am UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/2 "2024-11-22T07:52:12Z")
Maybe I need to describe it better:
- you have a weekly repeated event Monday evening 7-8pm
- some people have clicked going, interessted or not coming and this is shown by the respective symbol on their listed avatar
- next Monday at 8:01pm all those symbols are gone, avatars stay listed but greyed out
- event topic then shows date of the Monday one week later and nobody “going” etc until the first users click again
Now I fiddled around with some visibility setting that the ones attended today are longer visible then 8pm or that the event is not deleted or anything like that…
But now their avatars are never reset and greyed out but all “going” participants are accumulated over weeks and shown as actively “going”
I can’t find the setting to make it the same as before, at 8pm the event is cleared and set to next week without any participants
Any hint where I can revert this?
And yes, I know, document your changes 🙂
---
### Author:  [@lindsey](https://meta.discourse.org/u/lindsey)
#### Post date: [December 3, 2024, 9:23pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/5 "2024-12-03T21:23:21Z")
Hi Ann — sorry for the delay here, but thanks for reaching out about this! You’re right, this was a recent change to RSVP to the current and future instances of recurring events. We’re discussing this internally to see how we might improve upon this further. I’ll follow up with more information once I have something to share!
---
### Author:  [@anko127](https://meta.discourse.org/u/anko127)
#### Post date: [December 12, 2024, 11:48am UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/6 "2024-12-12T11:48:23Z")
Hello @lindsey ,
do you have further information on this topic?
At the moment we are exporting the event to see who changed their state when and then remove them from the list manually.
That’s a bit of a hassle.
Thank you for any update
---
### Author:  [@lindsey](https://meta.discourse.org/u/lindsey)
#### Post date: [December 12, 2024, 4:09pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/7 "2024-12-12T16:09:07Z")
Hi @anko127 — thank you for following up! I can appreciate how much of a hassle this manual effort has been, and we definitely want to fix that up for you.
Our plan is to improve recurring events to allow people to choose whether they are RSVPing to the single upcoming event, or to every event in the series. We’re finalizing the design work now and then we’ll be getting this worked in front of our engineering team. I don’t have an ETA on when it will be fixed, but it will be in our “next up” projects so I should be back with an update soon.
---
### Author:  [@anko127](https://meta.discourse.org/u/anko127)
#### Post date: [June 25, 2025, 10:08am UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/8 "2025-06-25T10:08:45Z")
Any news here? Thank you
---
### Author:  [@anko127](https://meta.discourse.org/u/anko127)
#### Post date: [February 3, 2026, 11:08am UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/9 "2026-02-03T11:08:38Z")
Hello @lindsey ,
Do you have any update on this topic?
To Reset the participants list when the Event has passed.
Thank you
---
### Author:  [@lindsey](https://meta.discourse.org/u/lindsey)
#### Post date: [February 3, 2026, 5:31pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/10 "2026-02-03T17:31:44Z")
I’m afraid I don’t have an update for you, @anko127 — this is still in our backlog but we have not yet prioritized it for development. I’ll discuss with the team to see when we might be able to pick this up.
---
### Author:  [@anko127](https://meta.discourse.org/u/anko127)
#### Post date: [February 12, 2026, 2:41pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/11 "2026-02-12T14:41:15Z")
I think it was working when I startet using Discourse prior autumn 2024, could it just be a misconfigured setting like keeping History for the Event?
---
### Author:  [@Aurora](https://meta.discourse.org/u/Aurora)
#### Post date: [March 11, 2026, 7:10pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/12 "2026-03-11T19:10:50Z")
We are experiencing exactly the same issue described above.
In our community we run many recurring events (support groups, body doubling sessions, regular meetings). Because the participant list for recurring events is not reset, the list quickly becomes inaccurate and continues to grow over time. After a few weeks it no longer reflects who is actually attending a specific occurrence of the event.
This creates a lot of confusion for both organizers and participants.
Another problem for us is that the people who create and organize these events (group facilitators) cannot remove participants from the list. Even when we assigned category moderator permissions to them, they still cannot manage the attendee list. Only global moderators or admins seem to be able to remove participants.
Since we have many groups organizing their own events, it is not practical for admins to manually manage all participant lists.
For communities like ours that rely heavily on recurring events, this makes the RSVP functionality very difficult to use.
Are there any updates or plans to improve how recurring event attendance is handled?
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [March 30, 2026, 1:22pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/13 "2026-03-30T13:22:32Z")
> [@Aurora](#):
>
> In our community we run many recurring events (support groups, body doubling sessions, regular meetings). Because the participant list for recurring events is not reset, the list quickly becomes inaccurate and continues to grow over time.
I’m not 100% sure what is but it looks like this was indeed the intended behavior for recurring events. @j.jaffeux do you remember the use cases for not reseting “going” participants on recurring events? Like our weekly team calls?
> [@Aurora](#):
>
> Another problem for us is that the people who create and organize these events (group facilitators) cannot remove participants from the list. Even when we assigned category moderator permissions to them, they still cannot manage the attendee list. Only global moderators or admins seem to be able to remove participants.
Will be fixed by
[https://github.com/discourse/discourse/pull/38966](https://github.com/discourse/discourse/pull/38966)
---
### Author:  [@j.jaffeux](https://meta.discourse.org/u/j.jaffeux)
#### Post date: [March 31, 2026, 9:11am UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/14 "2026-03-31T09:11:02Z")
> [@zogstrip](#):
>
> I’m not 100% sure what is but it looks like this was indeed the intended behavior for recurring events. @j.jaffeux do you remember the use cases for not reseting “going” participants on recurring events? Like our weekly team calls?
Because we don’t have per date event entry I think.
---
### Author:  [@anko127](https://meta.discourse.org/u/anko127)
#### Post date: [April 10, 2026, 8:00am UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/15 "2026-04-10T08:00:03Z")
Hi there,
Thank you for looking into it.
> [@zogstrip](#):
>
> this was indeed the intended behavior
But this sounds like “ Working as designed, no bug” or are you still investigating how to provide this automatic reset after event expiry?
We would really appreciate this, thank you.
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [April 14, 2026, 7:52am UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/16 "2026-04-14T07:52:00Z")
> [@anko127](#):
>
> But this sounds like “ Working as designed, no bug” or are you still investigating how to provide this automatic reset after event expiry?
Yeah, it’s unfortunately more work than we can “allocate” on this plugin right now. We need to store each “dates” instead of just storing the “recurrence formula”. It’s planned, but no dates yet.
---
### Author:  [@lindsey](https://meta.discourse.org/u/lindsey)
#### Post date: [May 18, 2026, 2:49pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/17 "2026-05-18T14:49:22Z")
I’m happy to share that Discourse now supports more granular RSVPs on recurring events. Members can now choose between RSVPing to a single occurrence of the event, or to all future occurrences. You can learn more about this here:
> [@Improved Events: More flexible RSVPs for recurring events](https://meta.discourse.org/t/improved-events-more-flexible-rsvps-for-recurring-events/402827):
>
> When RSVPing to a recurring event, members can now indicate whether they’re going to just the next occurrence or to all future occurrences. This makes it easier for event organizers to understand who is actually attending a particular event, and ensures attendees only receive reminders for the events they want to attend. microscope What’s changed On recurring events, the Going button now has a drop-down menu where members can choose to attend: This event: They are marked as “going” for the …
---
### Author:  [@anko127](https://meta.discourse.org/u/anko127)
#### Post date: [June 11, 2026, 2:06pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/18 "2026-06-11T14:06:49Z")
UPDATE: for the monthly event it is working, users are reset after the event is over. ONLY until then the series of events shows up in my event calender, even only the first one was confirmed.
Original post: Sorry Lindsey , but there must be a hidden option to prevent the reset of "going "users and I must have hit a year ago or even earlier in our system!
I’m quite sure you implemented this new option so that one-time-goers are reset after the event has passed. But I tested it on our system and after the event was over I was still there with the little hook:
I made a daily repeated event, I clicked Dabei= going at 13:40 and it showed me with the little hook. But now 15:38 it’s long past the end time, and it still shows me as registered ( for tomorrow) , even though, I have not clicked the “dabei” button again.
And investigating further: the side menu point upcoming events - switching to my events → shows me registered to all recurring events ( blue the daily one, pink a monthly one). I double checked, I really registered only for the next occurrence as you see in the picture above …
Does any other option needs to be enabled / disabled to make this work?
What have I broken? Could it be with time zone or language settings?
---
### Author:  [@lindsey](https://meta.discourse.org/u/lindsey)
#### Post date: [June 11, 2026, 4:43pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/19 "2026-06-11T16:43:54Z")
Interesting, thanks for sharing! Let us look into this and we will get back to you.
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [June 11, 2026, 10:18pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/23 "2026-06-11T22:18:41Z")
Thanks @anko127 for the report 👍
There is indeed a problem was the **My events** calendar showing the event on _every_ upcoming occurrence even when you’d only RSVPed to the next one.
>
>
> Addresses the \*\*My events\*\* calendar issue reported in \[meta t/335780\](https://m…eta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780), and improves how the event popup loads.
>
> \## FIX: Single-occurrence RSVPs filled the "My events" calendar
>
> When a member RSVPs "going" to only the next occurrence of a recurring event (not the whole series), the personal \*\*My events\*\* calendar — and the personal ICS feed — listed the event on \_every\_ occurrence instead of just the one they joined.
>
> \`EventFinder\` matches an event for \`attending\_user\` whenever the member is a "going" invitee, ignoring the invitee's \`recurring\` flag, and the events endpoint then expands the full recurrence series. The per-occurrence invitee list already filtered single RSVPs out of future occurrences, but the calendar/feed query did not.
>
> \`ExpandOccurrences\` gains a \`current\_occurrence\_only\` option that returns only the event's current occurrence (when it falls inside the requested window). \`EventsController#index\` sets it for the attending member's non-recurring "going" RSVPs, in both the JSON and ICS responses. RSVPs to every occurrence still expand fully; the non-personal calendars (all events / category) are unaffected.
>
> This is a targeted fix — properly modelling per-occurrence RSVPs (storing each date instead of only the recurrence formula) remains a larger follow-up.
>
> \## UX: Render event popup details immediately instead of a spinner
>
> Clicking an event opened a popup that showed only a loading spinner until a full event fetch resolved — slow on poor connections. The component wrapped its whole body in \`DAsyncContent\`, blocking every field on the request even though the calendar already provides each event's core fields (\`BasicEventSerializer\`) and the inline post widget provides the complete event (\`EventSerializer\`).
>
> It now renders the data already on the client immediately (title, date, recurrence) and fills in the rest (creator, attendees, RSVP buttons) when the background request returns. Inline event widgets in a topic render fully with no fetch at all (and no longer fire a redundant request). Still-loading sections use core's \`.placeholder-animation\` shimmer.
>
> \## Testing
>
> \- Request spec — single-occurrence RSVP returns one occurrence; all-occurrences RSVP returns the series.
> \- Service spec — \`current\_occurrence\_only\` returns the current occurrence only when it is inside the window.
> \- System spec — a daily recurring event RSVPed once shows a single tile on \`/upcoming-events/mine\`.
> \- Existing popup integration + system specs cover the immediate-render behaviour.
---
### Author:  [@anko127](https://meta.discourse.org/u/anko127)
#### Post date: [June 12, 2026, 6:49am UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/25 "2026-06-12T06:49:13Z")
Thanks, that was fast!
---
### Author:  [@zogstrip](https://meta.discourse.org/u/zogstrip)
#### Post date: [July 2, 2026, 2:57pm UTC](https://meta.discourse.org/t/repeating-event-going-gets-not-deleted-anymore/335780/27 "2026-07-02T14:57:49Z")