[meetup] Create one event across several groups in a network - #2
Merged
Conversation
A Pro network cross-posts the same session to every group in it, but the package could only ever target one group per run, so an adopter had to invoke it N times and stitch the results together by hand. Config gains `groups` (extra urlnames beyond `groupUrlname`) and `groupHosts` (per-group host names). Per-group hosts matter: groups in a network almost always have different organizers, so one `defaultHosts` rarely fits all of them. `resolveGroupTargets` expands config into the ordered, de-duplicated target list with hosts already resolved, and `createMeetupDrafts` walks it. Matching is case-insensitive throughout -- for the target list, the `--groups` filter and the `groupHosts` keys -- because Meetup urlnames are case-insensitive and a network reports e.g. CPPTORONTO where a config plausibly says cpptoronto. Groups are processed sequentially and one failure does not stop the rest; every outcome is reported so the caller can retry only what failed. There is deliberately no rollback, which the README calls out: a blind retry would duplicate the drafts that already succeeded. `--groups` is opt-in. Without it a run targets `groupUrlname` alone and --output keeps its single-event shape, so existing setups see no change; with it, --output carries a per-group breakdown and the exit code is 1 if any group failed. Not using CreateEventInput.proNetworkEvents was a deliberate call. It propagates via a saved filterId that no query exposes, so the set of groups it would reach is unverifiable from code. Naming groups is explicit and each draft stays individually reviewable. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The --output summary derived its status from every(r => r.ok), which is
true for dry runs too, so a --dry-run --groups run wrote
{"status":"created"} -- a lie a caller could act on, and exactly the kind
of thing a CI step would branch on.
aggregateStatus now returns "partial" if any group failed, otherwise the
status the groups agree on ("dry-run" or "created"), or "mixed" if they
somehow disagree.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
duxi90
added
documentation
5 tasks
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
groupsandgroupHostsconfig keys: one run creates the same event in everygroup of a Pro network, with per-group hosts.
resolveGroupTargetsexpands config intoan ordered, de-duplicated target list;
createMeetupDraftswalks it.--groups <names|all>on both create commands opts in. Without it a run targetsgroupUrlnamealone and--outputkeeps its single-event shape.reports
CPPTORONTOwhere a config plausibly sayscpptoronto.and the exit code is 1 if any group failed.
There is deliberately no rollback on partial failure (the README says so) — a blind retry
would duplicate the drafts that already succeeded.
CreateEventInput.proNetworkEventsgoes unused for a related reason: it propagates through a saved
filterIdthat no queryexposes, so the set of groups it would reach is unverifiable from code.
Motivation
A Pro network cross-posts the same session to every group in it; until now that meant
invoking the package once per group and stitching the results together by hand.
Testing
Tested locally. Full CI chain green (build, lint, format:check, typecheck, spell, test),
85 tests. Also ran
create-from-json --dry-run --groups allagainst a three-group config:targets resolve in config order, a
groupHostsoverride applies across a case mismatch(
cpptorontokey →CPPTORONTOtarget), and--outputreports each group separately.Nothing reaches the Meetup API.
Checkup list