tamakyi
b9060c982b
feat(notify): 新增站级 Webhook 与用户级 Telegram 通知通道
...
在现有邮件通知之外补两条广播/点对点通道：
- 站级 Webhook（[notify] webhook_url）：新提问 / 新回答 / 新追问 / 新私聊 /
新投票回复统一 POST JSON 到通用 Webhook（Discord / Slack / 企业微信机器人等）。
消息体同时带 content（Discord 直接可用）与结构化 event/title/body/link 字段。
- 用户级 Telegram（[notify] telegram_bot_token + users.telegram_chat_id）：箱主
自填 Chat ID，新提问 / 新投票回复点对点推送。
设计约束：通知是「尽力而为」旁路 —— 任一通道发送失败只记日志、不向上抛错，
绝不影响提问/回答的主流程；通道未配置时静默跳过。发送放在 shared.SafeGo 异步
执行，与现有邮件通知同一条路径。
6 处业务触发点接入 notify；私聊消息保留仅邮件（已有 5 分钟节流，避免广播刷屏）。
profile 页新增 Telegram Chat ID 输入框 + 四语言字典。app.sample.ini 加 [notify] 段。
测试覆盖 webhook 的 JSON 结构与未配置时的静默跳过。
2026-10-29 19:27:23 +08:00
tamakyi
d5d25c804b
fix(data): 删除改成一个事务且真删、配额与内容同事务
...
四类问题都出在「多次独立写入 + 失败只打日志」这个模式上。
1) 删除投票的级联没有事务（route/user/vote.go）
选项 / 表单字段 / 提交记录 / 投票本体是 4 次独立写入，前 3 步失败只 Warn。
中途失败会留下「选项没了但票还在」这种界面无法修复的状态 —— 重试删除时
投票已不存在，只能报 not exist，脏数据永远留着。
→ db.Votes.DeleteWithCascade：四张表在同一事务里删完。
2) 删除其实是软删除，个人数据没真删掉
模型都嵌了 dbutil.Model（含 DeletedAt），原来所有 Delete 都是软删：
提交记录里参与者填写的文本、voter_ip、voter_token，以及提问里的 FromIP，
只是「界面上看不见」，库里永久留着。用户点删除的预期不是这样。
软删还会占住 link_token 唯一索引，删过的链接永远不能复用。
→ 删除投票与删除提问统一 Unscoped 真删；提问的追问/图片关联/配额回退
原来也是三个独立写入（失败只 Warn），一并收进事务。
3) 配额计数会永久偏低
「创建内容」与「quota_count+1」是两次写入，后者失败只 Warn：
箱主看到的「已收集 7/10」偏小，达到上限后因为计数偏小实际还能继续收，
等于定量收集被静默绕过；重置计数也校准不回来（重置是把计数清零，更脱节）。
→ 抽出 incrementQuotaTx(tx, userID, feature, delta) 作为唯一实现，
提问 Questions.Create、私聊 CreateWithFirstMessage、投票提交
VoteSubmissions.Create（新增 QuotaUserID）都在自己的事务里完成 +1。
注意口径：投票的定量收集是「累计收到的票数」（提交成功时 +1），
不是「创建了几个投票」—— 所以删除投票不回退这个计数。
4) 改写追问回答每次都发通知邮件
箱主改措辞、补一句、修错别字都会重新保存，每次都发的话提问者会连着收到
好几封一模一样的「您的提问有回复」。主回答那边早有 question.Answer == ""
的判定，追问这里补齐：UpdateAnswerByID 在事务内读旧值返回 wasFirst。
顺带：
- isQuestioner 的 token 比较从 == 改为 subtle.ConstantTimeCompare，
与 Pager 中间件里的校验同口径（== 按字节短路，可用响应时间逐字节试探）。
- CSV 导出的表头（字段名）与选项内容列补 sanitizeCSVCell。原来只有数据列走它，
而选项名同样可能是 =HYPERLINK(...) 形式；判断也改成看 trim 后的首字符。
- 写路径的功能开关改 fail-closed：新增 db.FeatureStateOfStrict，读配置失败时
拒绝而不是回退默认配置 —— 提问/投票的默认值是「开启」，fail-open 等于让一次
数据库抖动绕过箱主设的关闭与定量上限。读展示仍用宽松版。
验证：全量单测（带 DB）与 go build ./... 通过；verify_round3 6/6（私聊
message_count 与实际消息数一致）、verify_p1 4/4、verify_round2 19/19、
verify_page_next 6/6、verify_chat_owner 3/3。
2026-10-29 17:18:28 +08:00
tamakyi
0124e392c7
fix(correctness): 三处幂等缺陷、私聊首条事务化、验证码失败不再丢正文
...
四处都属于「并发/失败路径下状态不一致」，用户侧表现为「点了没反应」「发了没收到」。
1) 删除会话重复回退配额
MarkDeletedByOwner 是 check-then-act：双击时两个请求都读到 is_deleted_by_owner=false，
都执行 UPDATE、都执行一次 IncrementQuota(-1)。计数不会变负，但会白吃掉其他会话的额度，
表现为定量收集提前关闭，箱主重置计数也校准不回来。
→ 改条件更新 + RowsAffected 决定是否回退。
2) 双击产生两条重复追问
「上一条追问必须先被回复」原来只在 handler 里判断（事务外）：两个请求都能通过那次检查，
随后被 CreateIfBelowLimit 的问题行锁串行化，各自 count 都 < 3 —— 两条相同追问都建成，
吃掉 2/3 名额，箱主还收两封邮件。
→ 判定挪进事务，新增 ErrFollowUpAwaitingReply；handler 的预检查保留作为快速失败。
3) 双击置顶结果与预期相反
SetPinned(id, !question.IsPinned) 是 read-modify-write：两个请求都读到 false 都写 true，
用户点两次期望「置顶后取消」，实际仍是「置顶」。
→ 新增 SetPinnedIfCurrent(current, next)，第二次因状态已变而 0 行，语义是「只切换一次」。
4) 私聊首条三步写入无事务
建会话 → 写首条消息 → 计数是三次独立写入，第二步失败会留下 message_count=0 的空会话，
箱主列表里能点进去却什么都没有；而 BeforeCreate 已占掉一个 6 字符 token（唯一索引），
孤儿会话永久占用它。
→ 新增 CreateWithFirstMessage，三步收进一个事务。
5) 验证码失败丢正文
该分支原来走 SetErrorFlash + Redirect，而其它失败分支都是 SetError + Success 回填表单。
验证码失败恰恰是最常见的失败（token 过期、网络抖动），结果用户写好的正文整段丢失。
→ 改为同请求渲染并回填；错误文案不再透传 err.Error()（可能含上游原始信息）。
6) 5 处裸类型断言改带 ok（share.go ×3 / context.go ×1 / user/vote.go ×1），
断言失败时丢弃脏缓存并走重建，而不是 panic 掉整个请求。share.go 的 ttlCache 补 Delete。
验证：内部 DB 测试 3 项（并发删除只回退一次配额 5→4、双击只产生一条追问、
双击只切换一次置顶）；verify_round3.py 6/6（验证码失败 200+正文回填+不建提问、
私聊首条 message_count 与实际消息数一致）。
2026-10-29 16:28:34 +08:00
tamakyi
4592b6ef24
fix v13
2026-10-19 01:58:00 +08:00
tamakyi
bd613a6f5a
fix v12
2026-10-19 01:11:28 +08:00
tamakyi
317c96ca17
restrict v7
2026-10-18 23:04:50 +08:00
tamakyi
d14d26df17
restrict v5
2026-10-18 21:59:12 +08:00
tamakyi
6bd90779f8
restrict v1
2026-10-18 21:14:59 +08:00
tamakyi
adcc42cc8c
fix anwser token and database issus
2026-09-15 11:06:09 +08:00
tamakyi
8e2325eda5
aliyun sensor server
2026-09-10 18:04:19 +08:00
tamakyi
e3e59e7c69
chore: baseline snapshot before moderation-strictness feature
...
Repo .git was damaged (refs/ missing, index truncated, object store near-empty).
Repaired via git init (rebuilt refs), stale index preserved as .git/index.corrupt-20260910.bak,
then full worktree committed as a rollback baseline.
2026-09-10 10:56:27 +08:00
tamakyi