GustavoandClaude Sonnet 5
abc690ddb7
Implements the actual send branch: Selecionar Top N -> Montar Mensagem ->
Guard de Envio -> Slack real -> registrar resultado (only after
confirmed success/failure) -- previously simulated/absent.
logic/slack.js (new): shouldSendByConfig (SEND_ENABLED gate, defaults
false), computeMessageHash (djb2Hash of the exact message text, reused
from logic/hash.js), alreadySentSuccessfully (idempotency check: only a
prior status='success' record for the same report_date+run_type+
message_hash blocks a resend -- a prior 'failed' record does not, so
retries after a real failure aren't stuck), evaluateSendGuard (single
auditable decision combining both), buildEnvioDigestRecord.
logic/slack.test.js: 13 tests covering all of the above, explicitly
labeled against the mission's required tests #13-#16.
New node drivers:
- guard-envio-slack.node.js: reads the digest + recent envio records
(fetched by report_date), computes the send decision.
- Slack node itself (n8n-nodes-base.slack, native, not a raw webhook):
reuses the real "Slack account" credential (slackApi) and
$vars.SLACK_CHANNEL_TECNICO channel variable already used by this
org's own "Notificacao de Erros Globais" workflow on the same n8n
instance -- V1's own Slack webhook URL was never actually deployed
(its Config value is literally "SEU/WEBHOOK/AQUI", same class of
placeholder as the old GLPI URL from the prior cycle), so this reuses
the one REAL, credentialed Slack mechanism that exists in this
environment rather than inventing a new destination. onError:
continueErrorOutput splits success/failure into two branches.
- registrar-envio-sucesso.node.js / registrar-envio-falha.node.js: build
the success/failure record; only the success path continues to the
existing per-ticket send-counter logic (rewired below).
- lancar-erro-envio.node.js: after the failure record is written,
explicitly throws so the n8n execution shows status=error (never
silently swallow a send failure).
- pular-envio.node.js: terminal no-op for the "should not send" branch
(SEND_ENABLED=false or already sent today), for observability only.
n8n/nodes/prepare-envio-record.node.js: rewired to read the Top10
selection by name ($('Code - Selecionar Top 10').all()) instead of
$input, since it now runs downstream of the Slack-success registration,
not directly off Selecionar Top10 -- registering per-ticket send counts
before Slack ever confirmed anything was the exact "don't register
before confirmation" bug the mission called out.
logic/message.test.js: added a full-Top10 message-length regression test
(mission requirement: message stays short, no leaked JSON/score/evidence).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
26 lines
1.1 KiB
JavaScript
26 lines
1.1 KiB
JavaScript
const ONE_DAY = 24 * 60 * 60 * 1000;
|
|
|
|
// So roda depois de "Data Table - Registrar Envio Digest (Sucesso)" -- ou seja, so depois do
|
|
// Slack confirmar sucesso de verdade (missao "finalizacao para producao", secao 19). Os dados
|
|
// do Top10 sao lidos por nome (nao por $input, que aqui e o registro do envio, nao os tickets).
|
|
return $('Code - Selecionar Top 10').all()
|
|
.filter((item) => item.json._grupo === 'selected')
|
|
.map((item) => {
|
|
const data = item.json;
|
|
const memory = data.memory;
|
|
const sentRecently = memory && memory.last_sent_at != null && (data.now - memory.last_sent_at) < ONE_DAY * 1.5;
|
|
const consecutiveDaysSent = sentRecently && !data.contextChanged ? (Number(memory.consecutive_days_sent || 0) + 1) : 1;
|
|
const timesSent = (memory ? Number(memory.times_sent || 0) : 0) + 1;
|
|
const timesSent30d = (memory ? Number(memory.times_sent_30d || 0) : 0) + 1;
|
|
return {
|
|
json: {
|
|
ticket_id: data.ticket.id,
|
|
last_sent_at: data.now,
|
|
times_sent: timesSent,
|
|
times_sent_30d: timesSent30d,
|
|
consecutive_days_sent: consecutiveDaysSent,
|
|
updated_at: data.now,
|
|
},
|
|
};
|
|
});
|