Lab Vibe 5 — ตั้งเวลาเผยแพร่โพสต์ และพิสูจน์ว่ารันซ้ำได้

Lab นี้คือวันตรวจรับ ไม่ใช่วันสร้าง

สไลด์หน้า 24 ให้ Lab นี้เป็น "เขียน prompt ให้ AI ทำทั้งบล็อก E แล้วตรวจ" · เว็บนี้เลือกให้คุณทำเองเป็นก่อน — ข้อกำหนดทุกข้อในสไลด์คุณทำไปแล้วในบท 143–144 · ที่เหลือคือส่วนที่สำคัญที่สุดของการทำงานกับ AI: ตรวจรับให้เป็น

Lab นี้มี 4 ขั้น:

ขั้น 1 — ใบสั่งงาน prompts/05-jobs.md: ทุกบรรทัดมาจากบทไหน

ไฟล์นี้คือใบสั่งงานที่จะส่งให้ AI ทำบล็อก E ทั้งหมดในครั้งเดียว · หน้าตาเหมือน 04-content.md (บท 141): เป้าหมาย · ข้อกำหนด · ห้าม · เกณฑ์ตรวจรับ — สี่ส่วนของบท 121

สร้างไฟล์ prompts/05-jobs.md แล้วพิมพ์ตามนี้ทั้งไฟล์ (ก็อปมาจากสไลด์หน้า 24 · บรรทัดในวงเล็บคือที่เราเพิ่มจากของจริง และแก้ 2 คำ ดูกล่องเตือนข้างล่าง):

## เป้าหมาย

ตั้งเวลาเผยแพร่โพสต์ล่วงหน้าได้
พอถึงเวลา ระบบเผยแพร่เองและแจ้งคนติดตาม

## ข้อกำหนด

- เพิ่ม status (draft/scheduled/published) + scheduled_at
  + published_at พร้อม index ที่ scheduled_at
  (โพสต์เดิมทั้งหมดเป็น published · เติม published_at ด้วย rake task ที่รันซ้ำได้ ไม่ใช่ใน migration)
- ใช้ Solid Queue · เพิ่ม jobs: bin/jobs ใน Procfile.dev
  (development ใช้ DB เดียวกับข้อมูล: ตาราง solid_queue_* มาจาก migration ไม่ต้องตั้ง connects_to)
- PublishPostJob ต้อง idempotent ด้วย guard สถานะ
  และต้องมี unique constraint ที่ DB กันสอง worker ชนกัน
  (guard สถานะอยู่ใน with_lock · unique index (post_id, follower_id) ของตารางที่จดว่าส่งอีเมลหาใครแล้ว)
- ใช้ท่า recurring job กวาดทุกนาที ไม่ใช่ wait_until
  (เพราะผู้ใช้แก้เวลาได้)
  (config/recurring.yml ต้องมี key development: ไม่งั้น bin/jobs ไม่กวาดในเครื่องเรา)
- retry_on พร้อม backoff แบบถ่างออก
- discard_on RecordNotFound
- ส่งเฉพาะ id เข้า job ห้ามส่งก้อนข้อมูล
- อีเมลใน development เขียนลงไฟล์ tmp/mails (delivery_method :file) ไม่ต้องลง service เพิ่ม

## ห้าม

- ส่งอีเมลใน callback ของ model
- ใช้ after_save (ต้อง after_commit)
- job ที่บวกเลขสะสมแทนการคำนวณใหม่
- ส่ง signed URL หรือ token เข้า job
- สมมติว่า job รันครั้งเดียว

## เกณฑ์ตรวจรับ

- [ ] ตั้งเวลา 1 นาทีข้างหน้า แล้วรอดู มันเผยแพร่เอง
- [ ] รัน PublishPostJob.perform_now(post.id) ซ้ำ 3 ครั้ง
      -> สถานะไม่เปลี่ยน และไม่มีอีเมลเพิ่ม (นับด้วย grep -c "^Subject:" tmp/mails/*)
- [ ] แก้เวลาที่ตั้งไว้ แล้วมันเผยแพร่ตามเวลาใหม่
- [ ] ปิด worker แล้วกด -> งานค้างในคิว ไม่หาย
      เปิด worker กลับมา -> งานถูกทำ
- [ ] เปิดตาราง solid_queue_* ดูด้วย SQL ได้

## = หัวข้อของ Markdown · - [ ] = ช่องติ๊กที่ยังไม่ติ๊ก · -> = "แล้วต้องได้ผลแบบนี้" · ใบสั่งนี้มีวงเล็บเยอะกว่าใบสั่ง 04 เพราะบล็อก E มีกับดักเงียบหลายจุด (ไม่มี error ให้เห็น งานแค่ไม่เกิด) — ถ้าไม่เขียนบอก AI จะตกหลุมเดียวกับที่สไลด์ตก:

ขั้น 2 — ตรวจรับ 5 ข้อของสไลด์หน้า 24 ด้วยของจริง

เตรียมโต๊ะตรวจ

เช็คก่อนว่าพนักงานหลังร้านมาครบ 4 ตำแหน่ง (หน้าต่างที่สอง ระหว่างที่ bin/dev เปิดอยู่):

$ bin/rails runner 'p SolidQueue::Process.pluck(:kind)'
["Supervisor(fork)", "Dispatcher", "Worker", "Scheduler"]

SolidQueue::Process = ตารางรายชื่อพนักงานที่กำลังเข้ากะ · pluck(:kind) = ขอแค่คอลัมน์ "ตำแหน่ง" · Worker หยิบใบงานไปทำ · Scheduler คือคนที่เดินตรวจกระดานทุกนาที (บท 144) · ถ้าไม่มี "Scheduler" = recurring.yml ไม่มี key development: หรือแก้ไฟล์แล้วยังไม่ได้ปิด-เปิด bin/dev ใหม่

แล้วล้างกล่องจดหมายทดลองให้เริ่มนับจากศูนย์ (อีเมลจากบท 144 ยังอยู่ในนั้น):

$ rm -rf tmp/mails

tmp/mails/ มีไฟล์ละผู้รับ (อีเมลใหม่ต่อท้ายไฟล์เดิม) · ลบทิ้งได้ไม่เสียอะไร · Rails สร้างโฟลเดอร์ใหม่เองตอนส่งฉบับถัดไป

ข้อ 1 — ตั้งเวลา 1 นาทีข้างหน้า แล้วรอดู มันเผยแพร่เอง

1. Chrome ไปที่ localhost:3000/posts/new · หัวข้อ ตั้งเวลา 1 นาที · เนื้อหาอะไรก็ได้ · เลือกหมวด
2. เลือก ตั้งเวลาเผยแพร่ · ช่องเวลาใส่นาทีถัดไป (ตอนนี้ 10:50 → ใส่ 10:51) · กดบันทึก

ผลจริงของผม (กดบันทึกตอน 10:50:23) — หน้า show ขึ้นกล่องสีฟ้า:

ตั้งเวลาเผยแพร่ไว้ 10/11/2026 10:51 · ยังไม่โชว์ในหน้ารวม
[เผยแพร่ทันที]

จด id จาก URL ไว้ (ของผมคือ /posts/31) · ไม่ต้องกดอะไรอีก — แค่รอ แล้วรีเฟรชหน้านี้หลังขึ้นนาทีใหม่ · ถ้าอยากเห็นในตู้แฟ้มตรง ๆ ใช้ psql (โปรแกรมคุยกับ Postgres ด้วย SQL ที่อยู่ใน container) แทน id เป็นของคุณ:

$ docker compose exec postgres psql -U postgres -d wongnok_blog_all_in_one_development \
    -c "SELECT id, status, scheduled_at, published_at FROM posts WHERE id = 31;"

# ตอน 10:50:54 (เวลาไทย)
 id |  status   |    scheduled_at     | published_at
----+-----------+---------------------+--------------
 31 | scheduled | 2026-11-10 03:51:00 |
(1 row)

# ตอน 10:51:06
 id |  status   |    scheduled_at     |        published_at
----+-----------+---------------------+----------------------------
 31 | published | 2026-11-10 03:51:00 | 2026-11-10 03:51:00.733052
(1 row)

• 03:51:00 = 10:51 เวลาไทย (UTC ช้ากว่า 7 ชั่วโมง) · published_at ห่างจากเวลาที่ตั้งไว้ไม่ถึง 1 วินาที — เพราะตัวกวาดรันต้นนาทีพอดี
• รีเฟรช /posts/31 → กล่องสีฟ้าหายไป · หน้า /posts มีบทความนี้อยู่บนสุด

ใครเป็นคนเผยแพร่? ดูใน log/development.log (log ของ job อยู่ที่นี่ ไม่ได้อยู่ในหน้าต่าง bin/dev ทั้งหมด · ตัดมาเฉพาะบรรทัดสำคัญ):

SolidQueue-1.7.0 Enqueued recurring task (56.7ms)  task: "publish_scheduled_posts", active_job_id: "7392816a-…", at: "2026-11-10T03:51:00Z"
[ActiveJob] [PublishScheduledPostsJob] [7392816a-…] Performing PublishScheduledPostsJob (Job ID: 7392816a-…) from SolidQueue(default) enqueued at 2026-11-10T03:51:00.048767000Z
[ActiveJob] [PublishScheduledPostsJob] [7392816a-…] Enqueued PublishPostJob (Job ID: 9191a520-…) to SolidQueue(default) with arguments: 31
[ActiveJob] [PublishScheduledPostsJob] [7392816a-…] Performed PublishScheduledPostsJob (Job ID: 7392816a-…) from SolidQueue(default) in 107.73ms
[ActiveJob] [PublishPostJob] [9191a520-…] Performing PublishPostJob (Job ID: 9191a520-…) from SolidQueue(default) enqueued at 2026-11-10T03:51:00.716798000Z with arguments: 31
[ActiveJob] [PublishPostJob] [9191a520-…] Performed PublishPostJob (Job ID: 9191a520-…) from SolidQueue(default) in 78.19ms

• บรรทัด 1 — Scheduler แขวนใบงาน "กวาด" ตอน 03:51:00Z (ต้นนาที · Z = เวลา UTC)
• บรรทัด 3 — ตัวกวาดเจอบทความ 31 ถึงเวลาแล้ว จึงแขวนใบงาน PublishPostJob ให้ · with arguments: 31 = ส่งแค่ id ตามข้อกำหนด
• บรรทัด 5–6 — worker หยิบใบงานนั้นไปทำ: เปลี่ยนสถานะ + ส่งอีเมล 3 ฉบับ ใช้ 78 ms (ของคุณจะต่าง)

นับอีเมล — คำสั่งเดียวกับที่เขียนในใบสั่ง:

$ grep -c "^Subject:" tmp/mails/*
tmp/mails/boss@example.com:1
tmp/mails/malee@example.com:1
tmp/mails/somchai@example.com:1

grep -c = นับบรรทัดที่ตรงเงื่อนไข · "^Subject:" = บรรทัดที่ขึ้นต้นด้วย Subject: (อีเมลหนึ่งฉบับมีหนึ่งบรรทัด) · tmp/mails/* = ทุกไฟล์ในโฟลเดอร์ → ได้ผลแยกรายคน · เนื้ออีเมลในไฟล์เป็นรหัส base64 (เพราะมีภาษาไทย) เปิดอ่านตรง ๆ ไม่ออก · อยากอ่านให้เปิด localhost:3000/rails/mailers/post_mailer/published หรือ:

$ bin/rails runner 'm = Mail.read("tmp/mails/malee@example.com"); puts m.subject; puts m.text_part.decoded'
บทความใหม่: ตั้งเวลา 1 นาที
มีบทความใหม่ใน Wongnok Blog

ตั้งเวลา 1 นาที

ทดลองตั้งเวลาเผยแพร่ หนึ่งนาที

อ่านต่อ: http://localhost:3000/posts/31

ส่งถึง malee@example.com เพราะคุณติดตาม Wongnok Blog

Mail.read อ่านได้เฉพาะฉบับแรกของไฟล์ · ✅ ข้อ 1 ผ่าน

ข้อ 2 — perform_now ซ้ำ 3 ครั้ง สถานะไม่เปลี่ยน อีเมลไม่เพิ่ม (หัวใจของบล็อก E)

สไลด์หน้า 24 เขียนกำกับข้อนี้ว่าเป็นเกณฑ์ที่ AI โกงไม่ได้เลย — AI เขียนได้ว่า "job นี้ idempotent แล้วครับ" แต่มันทำให้ grep นับได้ 1 ด้วยคำพูดไม่ได้ · บทความ 31 เผยแพร่ไปแล้วจากข้อ 1 → เหมือนสถานการณ์ "worker ตัวแรกทำเสร็จ แล้วใบงานเดิมโผล่มาอีก 3 รอบ"

เปิด console (bin/rails console) แล้วพิมพ์ทีละบรรทัด:

wongnok-blog-all-in-one(dev):001> post = Post.find(31); post.status
=> "published"
wongnok-blog-all-in-one(dev):002> post.published_at
=> 2026-11-10 10:51:00.733052000 +07 +07:00
wongnok-blog-all-in-one(dev):003> 3.times { PublishPostJob.perform_now(post.id) }
=> 3
wongnok-blog-all-in-one(dev):004> post.reload.status
=> "published"
wongnok-blog-all-in-one(dev):005> post.published_at
=> 2026-11-10 10:51:00.733052000 +07 +07:00
wongnok-blog-all-in-one(dev):006> post.post_notifications.count
=> 3

• perform_now = ทำใบงานทันทีในหน้าต่างนี้ ไม่ผ่านกระดาน (ต่างจาก perform_later ที่แขวนให้ worker) — เหมาะกับการซ้อมเพราะเห็นผลทันที
• 3.times { … } = ทำของในวงเล็บปีกกา 3 รอบ · => 3 คือค่าที่ times คืนมา (จำนวนรอบ) ไม่ได้แปลว่าส่ง 3 ฉบับ
• reload = โหลดค่าใหม่จากตู้แฟ้ม (ไม่งั้นได้ค่าเก่าที่ถืออยู่ในมือ) · สถานะกับ published_at เหมือนก่อนรันทุกตัว
• post_notifications.count = 3 แถว = ผู้ติดตาม 3 คน คนละแถว

ระหว่างนั้น console พิมพ์ SQL ออกมาด้วย · หนึ่งรอบหน้าตาแบบนี้ (ตัดคำสั่ง SELECT ออก):

Performing PublishPostJob (Job ID: b71ea82b-…) from SolidQueue(default) with arguments: 31
  Post Load (1.2ms)  SELECT "posts".* FROM "posts" WHERE "posts"."id" = 31 LIMIT 1 FOR UPDATE
  TRANSACTION (1.0ms)  COMMIT
  TRANSACTION (0.3ms)  BEGIN
  PostNotification Create (0.7ms)  INSERT INTO "post_notifications" ("post_id", "follower_id", "created_at", "updated_at") VALUES (31, 1, …) RETURNING "id"
  TRANSACTION (0.3ms)  ROLLBACK
  … (follower 2 และ 3 เหมือนกัน: INSERT แล้ว ROLLBACK)
Performed PublishPostJob (Job ID: b71ea82b-…) from SolidQueue(default) in 34.57ms

• FOR UPDATE = with_lock ล็อกแถวบทความระหว่างดูสถานะ (บท 143) · ไม่มีบรรทัด UPDATE "posts" เลย = guard สถานะเห็นว่าเผยแพร่แล้ว ไม่ทำซ้ำ
• INSERT แล้ว ROLLBACK = พยายาม "จองแถว" (บทความ 31, ผู้ติดตาม 1) แต่ชน unique index เพราะมีแถวนี้แล้ว → ยกเลิกทั้งก้อน รวมถึงการส่งอีเมล → ข้ามไปคนถัดไป (บท 144)

แล้วนับอีเมลจริงอีกรอบ:

$ grep -c "^Subject:" tmp/mails/*
tmp/mails/boss@example.com:1
tmp/mails/malee@example.com:1
tmp/mails/somchai@example.com:1

ยังคนละ 1 ฉบับ · ✅ ข้อ 2 ผ่าน — แต่ "ผ่าน" ยังไม่พอ ต้องรู้ด้วยว่าตัวไหนทำให้ผ่าน

ข้อ 2 ภาคต่อ — ทำให้พังโดยตั้งใจ ทีละตัวกัน

job ของเรามีตัวกันซ้ำ 2 ชั้น (บท 143–144): ชั้นแรก guard สถานะ (if post.scheduled? …) · ชั้นที่สอง จองแถวก่อนส่ง (PostNotification.create! + unique index) · สไลด์บอกว่า "ถ้า job ไม่ idempotent จะเห็นอีเมล 3 ฉบับทันที" — ลองดูว่าถอดชั้นไหนแล้วเห็นจริง

การทดลอง ก — ถอด guard สถานะ · เปิด app/jobs/publish_post_job.rb ใส่ # หน้าบรรทัด if กับ end ที่ครอบ update! (ผลจาก git diff):

     post.with_lock do
       # guard สถานะ: เผยแพร่แล้ว เป็นฉบับร่าง หรือยังไม่ถึงเวลา (ผู้ใช้เลื่อนเวลาออกไป) → ไม่ทำอะไร
-      if post.scheduled? && post.scheduled_at <= Time.current
+      # if post.scheduled? && post.scheduled_at <= Time.current
         post.update!(status: :published, published_at: Time.current)
-      end
+      # end
     end

บรรทัด - = ของเดิม · + = ของใหม่ · ตอนนี้ update! ทำทุกรอบไม่ว่าสถานะอะไร · ล้างกล่องจดหมาย (rm -rf tmp/mails) แล้วเปิด console ใหม่:

wongnok-blog-all-in-one(dev):001> post = Post.find(31); post.published_at.strftime("%T.%L")
=> "10:51:00.733"
wongnok-blog-all-in-one(dev):002> 3.times { PublishPostJob.perform_now(post.id); puts post.reload.published_at.strftime("%T.%L") }

10:54:02.512
10:54:02.636
10:54:02.649
=> 3
wongnok-blog-all-in-one(dev):003> post.status
=> "published"

$ grep -c "^Subject:" tmp/mails/*
grep: tmp/mails/*: No such file or directory

เอา guard กลับก่อนไปต่อ (และคืนเวลาเผยแพร่ด้วย ไม่งั้นบทความ 31 จะจำเวลาที่เพี้ยนไว้):

$ git restore app/jobs/publish_post_job.rb

git restore <ไฟล์> = ทิ้งทุกอย่างที่แก้ในไฟล์นั้นตั้งแต่ commit ล่าสุด · published_at ของบทความ 31 ไม่ต้องสนก็ได้ (เป็นบทความทดลอง) — แต่ถ้าอยากคืน ใน console: Post.find(31).update_columns(published_at: Time.zone.parse("2026-11-10 10:51")) (แก้วันเวลาให้ตรงของคุณ · update_columns = เขียนลงตู้ตรง ๆ ไม่ผ่าน validation/callback)

การทดลอง ข — ถอดการจองแถว · ในไฟล์เดียวกัน เมธอด notify ใส่ # หน้าบรรทัด create!:

       PostNotification.transaction do
         # จองก่อนส่ง: ใส่แถว (post, follower) ได้ = ได้สิทธิ์ส่ง
-        PostNotification.create!(post: post, follower: follower)
+        # PostNotification.create!(post: post, follower: follower)
         PostMailer.with(post: post, follower: follower).published.deliver_now
       end

$ rm -rf tmp/mails
wongnok-blog-all-in-one(dev):001> post = Post.find(31); post.status
=> "published"
wongnok-blog-all-in-one(dev):002> 3.times { PublishPostJob.perform_now(post.id) }
wongnok-blog-all-in-one(dev):003> post.reload.status
wongnok-blog-all-in-one(dev):004> post.post_notifications.count

wongnok-blog-all-in-one(dev):002> 3.times { PublishPostJob.perform_now(post.id) }
PostMailer#published: processed outbound mail in 24.3ms
Delivered mail 6af29574789f2_…@….local.mail (4.6ms)
Date: Tue, 10 Nov 2026 10:54:28 +0700
From: from@example.com
To: somchai@example.com
… (console พิมพ์อีเมลทั้งฉบับ 9 รอบ ยาวหลายร้อยบรรทัด — ตัดออก)
=> 3
wongnok-blog-all-in-one(dev):003> post.reload.status
=> "published"
wongnok-blog-all-in-one(dev):004> post.post_notifications.count
=> 3

$ grep -c "^Subject:" tmp/mails/*
tmp/mails/boss@example.com:3
tmp/mails/malee@example.com:3
tmp/mails/somchai@example.com:3

$ git restore app/jobs/publish_post_job.rb
$ git status --short

git status --short ต้องว่าง (ไม่มีบรรทัดไหนออกมา) ก่อนไปข้อ 3 · ไฟล์ใน tmp/ ไม่โผล่เพราะอยู่ใน .gitignore

ข้อ 3 — แก้เวลาที่ตั้งไว้ แล้วมันเผยแพร่ตามเวลาใหม่

ข้อนี้ต้องรอ ~3 นาที · ตั้งเวลาเผื่อไว้ 2 นาที จะได้มีเวลากดแก้:

1. สร้างบทความใหม่ "แก้เวลาเผยแพร่" ตั้งเวลาอีก 2 นาทีข้างหน้า (ของผม: สร้างตอน 10:54:49 ตั้ง 10:56)
2. กด "แก้ไข" → ฟอร์มขึ้นเวลาเดิม 10:56 และตัวเลือก "ตั้งเวลาเผยแพร่" ติ๊กอยู่ → เปลี่ยนเป็น 10:58 → บันทึก
3. กล่องสีฟ้าต้องเปลี่ยนเป็น ตั้งเวลาเผยแพร่ไว้ 10/11/2026 10:58 · ยังไม่โชว์ในหน้ารวม
4. รอ แล้วดู psql (หรือรีเฟรชหน้า) เป็นระยะ

# ผลจริง เช็คทุก ~15 วินาที (เวลาซ้ายมือ = เวลาไทยตอนเช็ค · ในตาราง = UTC)
10:55:43  32|scheduled|2026-11-10 03:58:00|
10:56:13  32|scheduled|2026-11-10 03:58:00|     ← ผ่าน 10:56 (เวลาเก่า) ไปแล้ว ยังไม่เผยแพร่
10:57:44  32|scheduled|2026-11-10 03:58:00|
10:57:59  32|scheduled|2026-11-10 03:58:00|
10:58:14  32|published|2026-11-10 03:58:00|2026-11-10 03:58:00.398734

(ตัดบางบรรทัดที่ซ้ำกันออก · แบบ | คั่นได้จากการเติม -At ท้ายคำสั่ง psql = ไม่เอาหัวตาราง) ดูในตารางใบงานว่ามีใบงานเผยแพร่บทความ 32 ตอนไหนบ้าง:

$ docker compose exec postgres psql -U postgres -d wongnok_blog_all_in_one_development \
    -c "SELECT id, class_name, arguments::json->'arguments' AS args, created_at FROM solid_queue_jobs WHERE class_name = 'PublishPostJob' ORDER BY id;"
 id |   class_name   | args |         created_at
----+----------------+------+----------------------------
  2 | PublishPostJob | [31] | 2026-11-10 03:51:00.717452
 10 | PublishPostJob | [32] | 2026-11-10 03:58:00.378617
(2 rows)

• arguments::json->'arguments' = ดึงเฉพาะค่าที่ส่งเข้า job ออกมาจากก้อน JSON ที่ Solid Queue เก็บไว้ (อ่านผ่าน ๆ ได้ ไม่ต้องจำ)
• ใบงานของบทความ 32 มีใบเดียว สร้างตอน 03:58:00 (10:58) — ตอน 10:56 ไม่มีใครแขวนใบงานเลย เพราะตัวกวาดอ่านเวลาล่าสุดจากตู้แฟ้มทุกนาที
• ถ้าใช้ท่า wait_until (แขวนใบงานล่วงหน้าตอนบันทึก) จะมีใบงานของ 10:56 ค้างอยู่ และต้องคิดเรื่องยกเลิกใบเก่าเอง (บท 144) · ✅ ข้อ 3 ผ่าน

ข้อ 4 — ปิด worker แล้วกด → งานค้างในคิว ไม่หาย · เปิดกลับ → งานถูกทำ

1. ปิด bin/dev (Ctrl+C) แล้วเปิดแค่เว็บ: bin/rails server — ตอนนี้ไม่มีพนักงานหลังร้าน (เช็ค: bin/rails runner 'p SolidQueue::Process.pluck(:kind)' → ผลจริง [])
2. สร้างบทความใหม่แบบ "เก็บเป็นฉบับร่าง" (ของผม: "ปิด worker แล้วกด" id 33) → หน้า show กด เผยแพร่ทันที
3. รอสัก 1 นาที แล้วดูตาราง

ผลจริง: กดตอน 10:58:39 · หน้าขึ้น ส่งเข้าคิวเผยแพร่แล้ว และกล่องสีฟ้าเปลี่ยนเป็น ตั้งเวลาเผยแพร่ไว้ 10/11/2026 10:58 (ปุ่มนี้ตั้งเวลาเป็น "ตอนนี้" แล้วแขวนใบงาน · บท 143) · เช็คตอน 11:00:03:

$ docker compose exec postgres psql -U postgres -d wongnok_blog_all_in_one_development \
    -c "SELECT id, class_name, arguments::json->'arguments' AS args, created_at, finished_at FROM solid_queue_jobs WHERE class_name = 'PublishPostJob' ORDER BY id DESC LIMIT 1;" \
    -c "SELECT id, job_id, queue_name, created_at FROM solid_queue_ready_executions;" \
    -c "SELECT id, status, published_at FROM posts WHERE id = 33;"
 id |   class_name   | args |         created_at         | finished_at
----+----------------+------+----------------------------+-------------
 11 | PublishPostJob | [33] | 2026-11-10 03:58:39.473611 |
(1 row)

 id | job_id | queue_name |         created_at
----+--------+------------+----------------------------
 11 |     11 | default    | 2026-11-10 03:58:39.483583
(1 row)

 id |  status   | published_at
----+-----------+--------------
 33 | scheduled |
(1 row)

• -c หลายตัว = สั่ง SQL หลายคำสั่งในครั้งเดียว · \ ท้ายบรรทัด = คำสั่งยังไม่จบ ต่อบรรทัดถัดไป
• ใบงาน 11 ยังอยู่ · finished_at ว่าง = ยังไม่มีใครทำ · ตาราง solid_queue_ready_executions คือ "ใบงานที่พร้อมให้หยิบ" — แขวนรออยู่ 1 ใบ
• ใบงานไม่หายเพราะกระดานอยู่ในตู้แฟ้ม (Postgres) ไม่ได้อยู่ในหัวของพนักงาน — ต่างจากคิวในหน่วยความจำ (Async) ของบท 142 ที่ปิดเครื่องแล้วหายหมด

เปิดพนักงานกลับมา: ปิด bin/rails server แล้วเปิด bin/dev ตามเดิม · ผลจริง (เปิด worker ตอน 11:00:08 · ใบงานหมดกระดานตอน 11:00:10):

 id |   class_name   |        finished_at
----+----------------+----------------------------
 11 | PublishPostJob | 2026-11-10 04:00:09.860676
(1 row)

 count
-------
     0
(1 row)

 id |  status   |        published_at
----+-----------+----------------------------
 33 | published | 2026-11-10 04:00:09.797648
(1 row)

ใบงาน 11 เสร็จภายใน 2 วินาทีหลังเปิด worker · กระดานว่าง (count 0) · และสังเกต published_at = 11:00:09 ไม่ใช่ 10:58:39 ที่กดปุ่ม — job ตั้งเวลาเผยแพร่ตอนที่ทำจริง (Time.current ใน job) · grep -c ได้ +1 ฉบับต่อคน · ✅ ข้อ 4 ผ่าน

ข้อ 5 — เปิดตาราง solid_queue_* ดูด้วย SQL

ข้อนี้คือ "รู้ว่ากระดานอยู่ไหน และอ่านเองได้โดยไม่ต้องพึ่งหน้าจอสวย ๆ" · \dt = คำสั่งพิเศษของ psql "ขอรายชื่อตาราง":

$ docker compose exec postgres psql -U postgres -d wongnok_blog_all_in_one_development -c '\dt solid_queue_*'
                        List of tables
 Schema |               Name               | Type  |  Owner
--------+----------------------------------+-------+----------
 public | solid_queue_batch_executions     | table | postgres
 public | solid_queue_batches              | table | postgres
 public | solid_queue_blocked_executions   | table | postgres
 public | solid_queue_claimed_executions   | table | postgres
 public | solid_queue_failed_executions    | table | postgres
 public | solid_queue_jobs                 | table | postgres
 public | solid_queue_pauses               | table | postgres
 public | solid_queue_processes            | table | postgres
 public | solid_queue_ready_executions     | table | postgres
 public | solid_queue_recurring_executions | table | postgres
 public | solid_queue_recurring_tasks      | table | postgres
 public | solid_queue_scheduled_executions | table | postgres
 public | solid_queue_semaphores           | table | postgres
(13 rows)

13 ตาราง แต่ที่ต้องรู้จักมีแค่ 5 · รันทีละคำสั่ง (ใส่ใน -c "…" แบบข้างบน) ผลจริงหลังข้อ 4:

-- งานตามเวลาที่ลงทะเบียนไว้ (มาจาก config/recurring.yml)
SELECT key, schedule, class_name FROM solid_queue_recurring_tasks;
           key           |   schedule   |        class_name
-------------------------+--------------+--------------------------
 publish_scheduled_posts | every minute | PublishScheduledPostsJob

-- ตัวกวาดรันนาทีไหนบ้าง (3 รอบล่าสุด)
SELECT task_key, run_at, job_id FROM solid_queue_recurring_executions ORDER BY run_at DESC LIMIT 3;
        task_key         |       run_at        | job_id
-------------------------+---------------------+--------
 publish_scheduled_posts | 2026-11-10 03:58:00 |      9
 publish_scheduled_posts | 2026-11-10 03:57:00 |      8
 publish_scheduled_posts | 2026-11-10 03:56:00 |      7

-- พนักงานที่เข้ากะอยู่
SELECT kind, pid, last_heartbeat_at FROM solid_queue_processes ORDER BY id;
       kind       |  pid  |     last_heartbeat_at
------------------+-------+----------------------------
 Supervisor(fork) | 16274 | 2026-11-10 04:00:09.640604
 Dispatcher       | 16279 | 2026-11-10 04:00:09.66135
 Worker           | 16280 | 2026-11-10 04:00:09.663729
 Scheduler        | 16281 | 2026-11-10 04:00:09.665981

-- งานที่พังจน retry หมดแล้ว
SELECT COUNT(*) FROM solid_queue_failed_executions;
 count
-------
     0

-- ใบงานทั้งหมดที่เคยมี แยกตามชนิด
SELECT class_name, COUNT(*) FROM solid_queue_jobs GROUP BY class_name;
        class_name        | count
--------------------------+-------
 PublishPostJob           |     3
 PublishScheduledPostsJob |     8

• ตัวกวาดรอบล่าสุดคือ 03:58 แต่ตอนเช็คคือ 04:00 กว่า — นาที 03:59 กับ 04:00 หายไป เพราะ worker ปิดอยู่ช่วงข้อ 4 · ไม่เสียอะไร: รอบถัดไปกวาดจาก DB เจอเองทุกอย่างที่ถึงเวลา (ท่ากวาดทนกว่า · บท 144)
• last_heartbeat_at = "ยังหายใจอยู่" ล่าสุดเมื่อไร · ตัวเลขนี้ค้างนาน = พนักงานตาย · pid = เลขประจำ process ของเครื่อง (ของคุณต่าง)
• failed_executions = 0 = ไม่มีงานที่พังจนยอมแพ้ · ถ้ามี ต้องเปิดดู error ในแถวนั้น
• PublishPostJob 3 = ข้อ 1 · 3 · 4 (การทดลองในข้อ 2 ใช้ perform_now ไม่ผ่านกระดาน จึงไม่มีแถว) · ✅ ข้อ 5 ผ่าน

ที่ AI พลาดประจำในบล็อกนี้ — ข้อห้าม 5 ข้อของหน้า 24

เกณฑ์ตรวจรับบอกว่า "ทำได้" · ข้อห้ามบอกว่า "ไม่ได้แถมของอันตรายมา" — แต่ละข้อมีอาการ และมีวิธีตรวจด้วยคำสั่ง:

-rn = ค้นทุกไฟล์ในโฟลเดอร์ย่อย (r) และบอกเลขบรรทัด (n) · \| = "หรือ" ใน grep · ระวัง: grep -rn "after_" app/models จะเจอ after_create_commit ใน comment.rb จากบท 133 — อันนั้นถูก (ลงท้าย _commit) ไม่ใช่สิ่งที่ข้อห้ามพูดถึง

ขั้น 3 — เติมกฎ 16–18 ลง 00-context.md: คู่มือโตจาก 15 ข้อเป็น 18 ข้อ

ใบสั่ง 05-jobs.md ใช้ครั้งเดียวต่อบล็อก · ส่วน 00-context.md คือกฎถาวรของร้านที่ AI อ่านทุกครั้ง · เปิด prompts/00-context.md หาหัวข้อ ## รูปแบบการตอบ แล้วแทรกก้อนนี้ไว้ข้างบน (ต่อจากกฎข้อ 15 · มีบรรทัดว่างคั่นหัวข้อละบรรทัดเหมือนเดิม):

## กฎเพิ่มจากบล็อค Background jobs

16. สมมติเสมอว่า job จะถูกรันซ้ำ (retry · เข้าคิวซ้ำ · สอง worker หยิบพร้อมกัน)
    เปลี่ยนสถานะ: guard สถานะใน with_lock · งานที่ทำซ้ำไม่ได้ (อีเมล): unique index ที่ DB แล้วจองแถวก่อนทำ
    ห้ามนับด้วยการบวกเพิ่ม ให้นับจากจำนวนแถว
17. ส่งเฉพาะ id เข้า job แล้วโหลดสดตอน perform · ห้ามส่ง signed URL หรือ token
18. ตั้งเวลา = recurring job กวาดจาก DB (config/recurring.yml ต้องมี key ของ environment นั้น)
    ไม่ใช้ wait_until · ลืมเปิด bin/jobs = งานนอนในคิวเงียบ ๆ

ข้อห้าม "ส่งอีเมลใน callback" กับ "after_save" ไม่ย้ายมาเป็นกฎใหม่ — กฎข้อ 16–17 ครอบไว้แล้ว (ไม่มี callback = ไม่มีปัญหา after_save) · เลขกฎต้องตรงกับบทเรียน ถ้าเติมเกินมาจะเทียบกับบทหลัง ๆ ยาก

ขั้น 4 — เก็บเข้าโปรเจกต์

ดูก่อนว่าจะเก็บอะไร (ผลจริง — ต้องมีแค่สองบรรทัดนี้):

$ git status --short
 M prompts/00-context.md
?? prompts/05-jobs.md

ถ้ามี app/jobs/publish_post_job.rb โผล่มาด้วย = ยังไม่ได้ git restore หลังการทดลองในข้อ 2 → git diff ดูก่อน แล้ว restore

$ git add .
$ git commit -m "prompts: ใบสั่งงาน job ตั้งเวลา และกฎ 16–18"
[my-day3 ea11ef8] prompts: ใบสั่งงาน job ตั้งเวลา และกฎ 16–18
 2 files changed, 49 insertions(+)
 create mode 100644 prompts/05-jobs.md

49 insertions = 9 บรรทัดใน 00-context (หัวข้อ · บรรทัดว่าง · กฎ 6 บรรทัด · บรรทัดว่าง) + 40 บรรทัดของไฟล์ใหม่ · เลข commit ของคุณจะต่าง

ทางเลือก: ลอง vibe จริง — ให้ AI ทำบล็อก E ใหม่ แล้วตรวจด้วย checklist ชุดนี้

ทำหลัง commit ข้างบน · ไม่บังคับ · ขั้นตอนเหมือนบท 141 หัวข้อ "ทางเลือก" ต่างแค่จุดเริ่ม (commit prompts: ใบสั่งงาน rich text + รูปปก และกฎ 13–15) กับชื่อใบสั่ง (@prompts/05-jobs.md) · บทนี้ไม่โชว์ว่า AI ตอบอะไร (ของแต่ละคนต่างกันทุกครั้ง) · จ้องเป็นพิเศษ: ทำการทดลอง ข กับโค้ดของ AI ได้ไหม (มันมี "สมุด" หรือเปล่า) · recurring.yml มี development: ไหม · AI ใช้ bundle add แล้วได้ gem เวอร์ชันใหม่ที่ต้องดาวน์โหลดไหม

สรุปบล็อก E — ได้อะไรไปบ้าง

ประโยคข้อ ② ของวัน (สไลด์หน้า 32): exactly-once ไม่มีอยู่จริง — ออกแบบให้ทำซ้ำได้แทน · ตอนนี้คุณไม่ได้แค่จำประโยคนี้ แต่เห็นด้วยตาแล้วว่า "ทำซ้ำได้" หน้าตาเป็นยังไง (3 รอบ อีเมล 1) และ "ทำซ้ำไม่ได้" หน้าตาเป็นยังไง (3 รอบ อีเมล 3) · ประโยคข้อ ③ (cache) อยู่ในสไลด์ส่วนถัดไป ซึ่งเว็บนี้ยังไม่ได้ทำเป็นบทเรียน · บทนี้คือบทสุดท้ายของเว็บตอนนี้

ภารกิจ: พิสูจน์ซ้ำกับบทความใหม่ และตรวจข้อห้ามด้วยคำสั่ง

$ grep -rn "deliver_" app
app/jobs/publish_post_job.rb:43:        PostMailer.with(post: post, follower: follower).published.deliver_now
$ grep -rn "after_save" app
$ grep -rn "increment\|+= 1" app/models app/jobs
$ grep -rn "perform_later" app
app/jobs/publish_scheduled_posts_job.rb:11:      PublishPostJob.perform_later(post.id)
app/controllers/posts_controller.rb:72:      PublishPostJob.perform_later(@post.id)

Quiz

ถามกลับได้เลย

ติดข้อไหน ก็อปผลจริงจากเครื่องคุณ (log · ผล psql · ผล grep) ไปถามได้เลย · ตัวอย่างคำถามที่ดี: "ผมทำการทดลอง ข แล้ว grep ได้คนละ 3 แต่ post_notifications.count ยัง 3 — ทำไมตัวเลขสองตัวนี้ไม่ไปด้วยกัน" · "ถ้ามีผู้ติดตาม 10,000 คน job นี้ถือ lock ระหว่างส่งอีเมลนานไหม ควรแยกยังไง"

ถ้าเปิดสไลด์ดูประกอบ

อ้างอิง

• Rails Guides — Active Job: Retrying or Discarding Failed Jobs — สั้นมาก · อ่านตัวอย่าง retry_on/discard_on แล้วเทียบกับบรรทัดบน ๆ ของ publish_post_job.rb · retry ปลอดภัยเพราะ job รันซ้ำได้ (การทดลองในข้อ 2)
• rails/solid_queue README — Recurring tasks — ที่มาของ config/recurring.yml และตาราง solid_queue_recurring_tasks/_executions ในข้อ 5 · อ่านย่อหน้าที่บอกว่าไฟล์แยกตาม environment
• rails/solid_queue README — Jobs and transactional integrity — ทำไมคิวที่อยู่ใน DB เดียวกับข้อมูลต้องระวังเรื่อง transaction · ปูพื้นข้อห้าม after_save
• Rails API — ActiveRecord::Locking::Pessimistic — with_lock = SELECT … FOR UPDATE ที่เห็นใน log ข้อ 2 · อ่านตัวอย่างแรกพอ
• Rails Guides — Action Mailer: Previewing Emails — หน้า /rails/mailers/… ที่ใช้อ่านอีเมลภาษาไทยแทนการเปิดไฟล์ base64
• repo ของอาจารย์ — wongnok-blog-all-in-one — เลือก branch day3-e-done ถ้าอยากเทียบกับเฉลยของอาจารย์ · จำไว้ว่าไฟล์ต่างจากบทเรียนนี้ (Mailpit · DB คิวแยก)