galthran-wq / telegram-scraper-service

68%

push

github

fix: ship scripts/ in docker image + accept auth_key hex + DC input (#7)

* fix: ship scripts/ in docker image + accept auth_key hex + DC input

Two follow-ups from real dev-deploy testing:

1. Dockerfile only COPY'd src/, so scripts/add_session.py et al. were
   missing from the image and `make {dev,prod}-tg-add-session` failed.
   Adds COPY scripts/ scripts/.

2. Telegram-account marketplaces (lzt.market, lolz.live, ...) hand over
   either a Telethon StringSession or a raw auth_key hex (256 bytes =
   512 hex chars) plus a DC id. add_session.py now auto-detects the
   format: if stdin is exactly 512 hex chars, --dc <1-5> must be
   supplied and the script builds the StringSession via the new
   encode_string_session helper. Otherwise the input is treated as a
   StringSession as before. encode_string_session uses the standard
   DC bootstrap IPs and Telegram port 443.

Tests: encoder round-trips via Telethon's own StringSession parser
(verifies dc_id and auth_key.key match); also covers bad-input rejection.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* test: cover all 5 DCs, high-bit auth_key, non-hex input + _is_auth_key_hex

Review (subagent) caught minor test gaps. Adds:
- parametrize round-trip across DC 1..5 with varied auth_key byte
  patterns (0x01, 0x7f, 0xab, 0xff, 0x5c) so we catch struct-pack
  endianness or DC table mismatches
- explicit ValueError on non-hex input ("zz" * 256)
- direct unit test for _is_auth_key_hex matching the 512-hex-chars-only
  contract

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

14 of 14 new or added lines in 1 file covered. (100.0%)

539 of 791 relevant lines covered (68.14%)

0.68 hits per line