From 983bb1c500a63e7dee5905fb4025f8811e569994 Mon Sep 17 00:00:00 2001 From: Wyndham ARR Date: Thu, 8 Oct 2026 21:39:12 +0800 Subject: [PATCH] docs: record completed September 16 acquisition and button recovery --- .../30-worklog/tasks/20261008-production-review-9e7b.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md b/.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md index 28fc176..cb8256e 100644 --- a/.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md +++ b/.project-docs/30-worklog/tasks/20261008-production-review-9e7b.md @@ -228,3 +228,6 @@ Read: memory-index, project-positioning, current-state latest September sections - Immutable in-progress capture evidence at13:31:48UTC: search successfully returned209 reservations across3 pages;166 distinct reservation details,165 rate lookups and165 profile summaries have succeeded.500 recorded responses comprise499 HTTP200 and1 transport failure; the failed detail was retried and collection continued. The latest successful response ended13:31:47UTC and request501 is in progress. Earlier inspection at13:31:00 found request482, proving ongoing progress instead of a frozen stage. Counts describe source acquisition, not report eligibility or finished reports. - Independent read-only code audit confirms serial per-reservation enrichment, followed by optional room history and complete list recheck. Single HTTP calls have socket timeout/retries, but no whole-job wall-clock deadline. Current UI disables duplicate submission while queued/downloading/processing; it offers no inner-stage counts. Therefore the current disabled button is expected while this still-progressing9/16 task collects data; the lack of visible progress makes the long stage unclear. - Outcome: explain the actual running date, source count/progress and automatic transition after acquisition; leave the user's active request intact. No code change, tests, service restart, new Oracle call, task retry, cancellation, price/field decision or real report generation was performed. Promotion candidate: if requested, expose privacy-minimized acquisition counts and last response time rather than treating queue updated_at or worker health as progress or inventing a percentage from the request cap. Whole-job timeout/cancel behavior remains a separate product decision. +- User challenged the long wait. Same-task ownership/context were resumed and verified again. At13:35:22UTC, details reached195/209 (29 additional details/rates/profiles since13:31:48); latest response ended13:35:21. Successful request mean times: detail2.92s, rate2.20s, profile2.21s. This supports serial query latency as the dominant observed wait, without blaming Oracle for all overhead or claiming the complete request was stalled. At13:36:39, details reached205/209. +- Actual completion: last successful source response13:37:25UTC;209 details,209 rates,209 profiles,6 search pages including final recheck,1 room-calendar request;634 HTTP200 plus1 transport failure/retry. Capture result collection_complete=true,209 records,error=null. At13:37:31UTC (21:37 local computer time), the original request transitioned to needs_review after about26m13s. Authenticated read-only API reports existing price review open, revision0,0/5 completed. Missing raw observations do not imply5 source-field prompts: eligible source review passed into the existing price review. +- Fresh temporary authenticated browser verified selected9/16, “等待人工价格复核”, enabled “下载并处理” and “查看价格复核”, and0/5 review progress. No price form was edited or finalized. Closed the verification tab; existing user tabs and requests were untouched. This establishes both natural task completion and download-button recovery, with no restart/refetch/code change/test run. Speed optimization and visible progress are potential follow-ups; the current26-minute duration is observed poor product performance, not evidence of a deadlock.