fix(labels): renderizar JSON no GET/POST de labels (corrige 204 que apagava tags)#145
Open
agbid wants to merge 1 commit into
Open
fix(labels): renderizar JSON no GET/POST de labels (corrige 204 que apagava tags)#145agbid wants to merge 1 commit into
agbid wants to merge 1 commit into
Conversation
…pagava tags)
LabelConcern#index e #create setavam @labels mas não renderizavam nada, e não
há view jbuilder para o controller — então o Rails respondia 204 No Content com
corpo vazio. Isso quebrava qualquer consumidor do endpoint que lê os labels
atuais: a tool manage_conversation_labels do AI Processor faz GET antes de um
add, recebia 204 vazio, concluía "0 labels", e como o POST faz update_labels
(replace, não append) acabava apagando todas as etiquetas existentes — incluindo
atendimento_ia, que mantém a IA elegível. Sem ela, o postback seguinte dá 422 e
a resposta é descartada.
Correção: render json: { payload: @labels } em ambas as actions. Formato payload
é o esperado pelos consumidores (a tool normaliza via chave payload). O frontend
não consome este GET (lê labels por broadcast), então a mudança é de baixo risco.
Reviewer's guide (collapsed on small PRs)Reviewer's GuideAdds explicit JSON rendering for labels in the LabelConcern index and create actions so that GET/POST /labels return the current labels instead of a 204 No Content, preventing clients from mistakenly clearing existing labels. Sequence diagram for GET/POST labels JSON renderingsequenceDiagram
actor Client
participant LabelsController
participant Model
Client->>LabelsController: GET /conversations/:id/labels
LabelsController->>Model: label_list
Model-->>LabelsController: label_list
LabelsController-->>Client: render json payload
Client->>LabelsController: POST /conversations/:id/labels
LabelsController->>Model: update_labels(labels)
LabelsController->>Model: label_list
Model-->>LabelsController: label_list
LabelsController-->>Client: render json payload
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
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
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.
Resumo
fe17f72(já presente emdevelop) paramaincomo hotfix.LabelConcern#indexe#createsetavam@labelsmas não renderizavam resposta, e não há view jbuilder — o Rails respondia 204 No Content com corpo vazio.GET /conversations/:id/labels(ex.: a toolmanage_conversation_labelsdo AI Processor) recebia 204 vazio, concluía "0 labels" e, como oPOSTfazupdate_labels(replace, não append), um "add" do agente apagava todas as labels existentes da conversa — incluindoatendimento_ia, que mantém a IA elegível para responder. Sem ela, o postback seguinte falha (422) e a resposta é descartada.Mudança
render json: { payload: @labels }emindexecreate(formatopayloadjá é o esperado pelos consumidores existentes).Descoberto via
Teste end-to-end do agente "Inter Rural - Atendimento" com
allow_manage_labels=true: umremovede label reportou sucesso ("None of the requested labels were present; nothing to update") mas a label permaneceu no banco — comportamento consistente comcurrent_labelssempre vindo[]por causa do 204.Test plan
GET /conversations/:id/labelsdeve retornar{"payload": [...]}com as labels reais (não 204).addde uma label em conversa que já tem outras labels deve preservar as existentes.removede uma label existente deve realmente removê-la (labelsresultante sem o item removido).Summary by Sourcery
Return labels as JSON payload from label create and index actions to prevent 204 responses that cleared conversation tags.
Bug Fixes: