Heroku Scheduler ile PostgreSQL bağlantısını kontrol etmek için uygulamanın çalıştıracağı küçük bir Python komutu hazırlıyorum. Komut SELECT 1 sonucunu doğruluyor; tablo oluşturma, kayıt silme veya tekilleştirme yapmıyor. Scheduler uygulama ortamında komut başlatır, PostgreSQL'in içine kendiliğinden bir job tanımlamaz.

Eski yazımdaki run_deduplicate_jobs() örneği yalnız bir bildirim mesajı yazıyordu. Bu mesaj kayıtların temizlendiğini göstermiyordu. Buradaki başarı ölçütü daha dar: bağlantı kurulmalı, sorgu beklenen sonucu vermeli ve komut sıfır koduyla bitmeli.

Test edilen ortam

7 Ekim 2026'da macOS 27.0.1 / arm64 üzerinde Docker Engine 29.8.0 ve Compose 5.5.1 ile izole test yaptım. Uygulama container'ı Debian GNU/Linux 13 (trixie), Python 3.13.16 ve psycopg2-binary 2.9.12 kullanıyordu. Ayrı, sentetik veritabanı PostgreSQL 17.11 idi. İmajlar örnek pakette digest ile sabitlenmiştir.

Yerel kontrol iki kez çalıştı; eksik bağlantı değişkeni ve bağlantı kurulamaması da test edildi. Heroku'da komut çalıştırma, Scheduler zamanlaması, one-off dyno ortamı ve üretim veritabanı test edilmedi. Yerel sonucu Heroku görevinin çalıştığına dair kanıt olarak sunmuyorum.

Salt okunur kontrol komutu

Örnek paketteki access-scheduler-validation/check_database.py dosyası DATABASE_URL değerini ortamdan okuyor. Bağlantı ve sorgu için beş saniyelik sınırlar kullanıyor. Sorgu salt okunur transaction içinde çalışıyor; beklenen sonuç (1, "on"):

with psycopg2.connect(database_url, connect_timeout=5) as connection:
    connection.set_session(readonly=True)
    with connection.cursor() as cursor:
        cursor.execute("SET LOCAL statement_timeout = '5s'")
        cursor.execute("SELECT 1, current_setting('transaction_read_only')")
        if cursor.fetchone() != (1, "on"):
            return 1

Bu alıntı sorgu kısmıdır; çalıştırılabilir dosyada eksik değişken ve sürücü hatası da yakalanır. Bağlantı dizgesi, parola ve sürücünün ayrıntılı hata metni loglanmaz. Psycopg bağlantı belgesi transaction ayarını, PostgreSQL bağlantı belgesi URI biçimini açıklıyor.

Yerel test ve gerçek çıktılar

Paketin access-scheduler-validation dizininde Docker çalışırken:

python lab.py init
python lab.py up
docker compose --env-file .env.local run --rm check
docker compose --env-file .env.local run --rm check
python lab.py verify

init, yalnız bu örnek için rastgele parola içeren .env.local üretir; mevcut dosyayı üzerine yazmaz. Compose içindeki veritabanı host'a port yayımlamaz. Başka bir uygulamanın .env veya DATABASE_URL değerini kopyalamaya gerek yoktur.

İki çalıştırmada da uygulamanın gerçek stdout çıktısı aynıydı; Compose'un container durum satırlarını burada atladım:

CHECK_OK select=1 transaction=read-only

İki komut da exit 0 verdi. Sorgu öncesinde ve sonrasında sentetik veritabanının public şemasındaki tablo sayısı 0 idi. Kod yalnız bağlantı kontrolü yapıyor; bu sonuç yedekleme, veri işleme veya kayıtların tekilleştirilmesi değildir. Aynı kontrolün ikinci kez çalışması veri değiştirmedi.

Hata testlerinde uygulamanın gerçek stderr çıktısı (yorum satırları açıklamadır; Compose durum satırları atlandı):

# DATABASE_URL boş: exit 2
CHECK_ERROR DATABASE_URL is required; value is not logged.
# Sentetik kapalı porta bağlantı: exit 1
CHECK_ERROR database connection or query failed; details are not logged.

Bu hata satırı bağlantı veya sorgunun başarısız olduğunu söyler; nedenin parola, adres veya veritabanı durumu olduğunu tek başına belirlemez. verify tarihli JSON sonucu kaydeder ve yerel parolanın kanıta sızmadığını kontrol eder. python lab.py down, yalnız bu örneğin container ve sentetik volume'unu kaldırır.

Heroku'da ayrıca doğrulanması gereken adım

Heroku uygulama imajına bu dosya ve uyumlu bağımlılık eklenirse Scheduler görev alanına python check_database.py yazılabilir. Bu test edilmemiş Heroku adımıdır; bu depoda canlı görevin kurulduğunu söylemiyorum. Önce uygulamanın one-off dyno ortamında aynı komutun çalıştığı ve exit 0 verdiği doğrulanmalı. Container Registry kullanılıyorsa görev dosyası web imajından erişilebilir olmalı.

Bağlantı bilgisini görev komutuna yerleştirmiyorum. Common Runtime komuttaki config var başvurularını loglamadan önce genişletebilir; sırları kod içinde okuyup değeri yazdırmamak gerekir. Bu davranış ve platform testi Heroku Scheduler belgesinde açıklanıyor.

Zamanlama ve sonuç farklı kontroller

Scheduler on dakikada bir, saatte bir veya günde bir seçenek sunar. Görev nadiren atlanabilir, iki kez çalışabilir veya önceki çalışmayla kısa süre örtüşebilir. Dolayısıyla tam bir “en az bir kez çalışır” garantisi de vermez. Eklenti ücretsiz olsa da görevlerin one-off dyno süresi kullanıma ve maliyete dahil olur. Sınırlar Heroku belgesinde yer alıyor.

Veri değiştiren gerçek bir görev için tekrar çalıştırma davranışı, etkilenecek kayıtları gösteren deneme modu ve sonucu doğrulayan ayrı sorgu gerekir. Logda “tamamlandı” yazması ile beklenen veri değişikliğini ölçmeyi aynı kanıt saymam. Bu yazıdaki örneğin kapsamı bağlantı kontrolünde kalıyor.