Skip to content

fix: correct payload structure in code-review-send-labels - #8

Open
ArthurHeymans wants to merge 1 commit into
doomelpa:masterfrom
ArthurHeymans:FixSettingGhubLabels
Open

fix: correct payload structure in code-review-send-labels#8
ArthurHeymans wants to merge 1 commit into
doomelpa:masterfrom
ArthurHeymans:FixSettingGhubLabels

Conversation

@ArthurHeymans

Copy link
Copy Markdown

The code-review-send-labels method was failing with "Wrong type argument: consp, nil" error when setting labels. The issue was caused by improper alist construction using a-alist function, which could return nil in certain cases.

Changes:

  • Extract label processing into explicit variables for clarity
  • Use vconcat to ensure label-names is always a vector
  • Replace a-alist with explicit backquote alist syntax to guarantee proper payload structure
  • Change let to let* for sequential variable binding

The payload now consistently creates ((labels . [vector])) structure that ghub expects, whether labels are present or being cleared.

The code-review-send-labels method was failing with "Wrong type argument: consp, nil" error when setting labels. The issue was caused by improper alist construction using a-alist function, which could return nil in certain cases.

Changes:
- Extract label processing into explicit variables for clarity
- Use vconcat to ensure label-names is always a vector
- Replace a-alist with explicit backquote alist syntax to guarantee proper payload structure
- Change let to let* for sequential variable binding

The payload now consistently creates ((labels . [vector])) structure that ghub expects, whether labels are present or being cleared.

Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
ykoor pushed a commit to ykoor/code-review that referenced this pull request Aug 7, 2026
…elpa#5, doomelpa#7)

- doomelpa#10: load ghub-legacy when ghub-graphql is not already defined,
  restoring compatibility with ghub 5.1 while keeping older releases
  working.
- doomelpa#8 and doomelpa#5: fix the payload structure in code-review-send-labels
  (vector of label names, correct post/put choice).
- doomelpa#7 (amended): instead of advising closql--abbrev-class, advise
  closql--coerce and closql--remake-instance to replicate closql
  2.4.0's Emacs 30 handling of EIEIO records.  The original advice
  only covered one call site of the same root cause.  Verified on
  Emacs 30.2 with closql 2.3.2 and 2.4.1, with
  eieio-backward-compatibility both enabled and disabled.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant