fix(logging): silence yfinance no-data ERROR-log flood + bump to 1.5.1

[Chen-zexi]

Summary

Two focused changes:

• Logging fix — the yfinance library logs a normal "no price data" soft-miss
  at ERROR level (and returns an empty result instead of raising), so every
  symbol Yahoo Finance can't serve — non-US tickers, thin/unlisted symbols — produced
  a steady flood of ERROR lines from the last-resort fallback provider. Our market-data
  provider chain already treats an empty result as a designed soft-miss / fallthrough,
  so these are not errors in our system. Pin the yfinance logger to CRITICAL in
  module_log_levels so the severity mismatch is corrected at the source. Genuine
  yfinance failures are still surfaced by our own data_client logger.
• Dependency bump — yfinance 1.4.0 → 1.5.1.

Overview

	Files	Lines
Modified	2	+10 / −3
New	0	—
Net (excl. tests)	2	+10 / −3

By module

• config.yaml (modified) — one new module_log_levels entry (yfinance: CRITICAL) plus an explanatory comment on why the level must be CRITICAL, not WARNING.
• uv.lock (modified) — yfinance 1.4.0 → 1.5.1.

What this introduces: quieter ERROR logs — removes a high-volume third-party noise
source — with zero change to data results or routing behavior.

Diff Size

• Total: 2 files changed, 10 insertions(+), 3 deletions(-)
• Net (excl. tests): 2 files changed, 10 insertions(+), 3 deletions(-)

Test Coverage

Config + lockfile only — no new application code paths to audit. Verified by driving
the real code path instead (below).

Pre-Landing Review

No issues. 13-line config/dependency diff — no SQL, no LLM trust-boundary, no secrets.

Verification

• Flood reproduced + fixed through the real configure_logging() path on 1.5.1:
  yfinance ERROR lines 6 → 0 for unservable symbols; empty results unchanged.
• API contract — every yfinance surface the code consumes (history, fast_info,
  info, income/cashflow statements, screener EquityQuery/screen, Search, news)
  verified present + shape-stable against 1.5.1 via static and live-shape checks.
• Happy path intact on 1.5.1: US daily + snapshot and non-US (.HK) daily all return data.

Test plan

• Full unit suite: 6043 passed (2 pre-existing failures unrelated to this diff — a local search-provider manifest env artifact)
• yfinance API contract verified against 1.5.1
• ERROR-flood suppression verified via the real logging path (6 → 0)

Summary by CodeRabbit

• Chores
  • Reduced noise from third-party market-data logging by limiting non-actionable messages to critical severity.
  • Added configuration comments clarifying handling of empty data results and fallback behavior.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 145002b0-48ce-4347-84ee-c379c213a554

📥 Commits

Reviewing files that changed from the base of the PR and between ab28cb9 and 1aa1217.

⛔ Files ignored due to path filters (1)

• uv.lock is excluded by !**/*.lock

📒 Files selected for processing (1)

• config.yaml

---

📝 Walkthrough

Walkthrough

The logging configuration sets yfinance to CRITICAL and documents its error-level no-data behavior and provider-chain fallthrough handling.

Changes

Logging configuration

Layer / File(s)	Summary
Configure yfinance logging config.yaml	Sets the yfinance log level to CRITICAL and explains the related provider fallback behavior.

Estimated code review effort: 1 (Trivial) | ~2 minutes

Poem

A rabbit tuned the logs just right,
So noisy errors fade from sight.
Yfinance speaks when troubles loom,
While empty data clears the room.
Critical notes still hop through—
A tidy trail for all to view.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly states the main changes: silencing yfinance log spam and bumping the dependency.
Description check	✅ Passed	The description covers the summary and test plan well, and includes change details, though it uses 'Overview' instead of the template's 'Changes' heading.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/yfinance-error-log-noise

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

Review

Small, well-scoped change (config + lockfile only). Verified the mechanics:

• yfinance is used as a bare (non-grouped) key in module_log_levels, which expand_module_log_levels() (src/config/logging_config.py:137-139) passes through as-is — logging.getLogger("yfinance").setLevel(CRITICAL) will apply to the library's root logger and cascade to children via Python's logging hierarchy, so the config key is correct.
• src/data_client/yfinance/data_source.py:151 wraps snapshot failures in its own try/except and logs via the data_client-namespaced logger.warning(...), which is untouched by this change — confirms the PR's claim that genuine failures caught at our boundary still surface.
• pyproject.toml pins yfinance>=1.2.0, so the 1.5.1 lock bump is compatible; no other lockfile deltas beyond the yfinance entry.

No blocking issues.

💡 Non-blocking: Setting the whole yfinance logger to CRITICAL suppresses all ERROR-level output from the library, not just the known "possibly delisted"/no-data soft-miss. If a future yfinance version logs a genuine ERROR-level condition that doesn't raise and isn't already caught at the data_source.py boundary (e.g. a rate-limit or auth warning), it'll now be silently swallowed with no equivalent visibility. A logging.Filter targeting the specific "possibly delisted" message (rather than a blanket level bump) would be more surgical, but given this is pinned to a known, verified noise source and the PR did live before/after verification (6→0 ERROR lines), this is a reasonable tradeoff as-is — just flagging for awareness, not requesting a change.

[github-actions]

Hot Path Integration Test Results

⏱️ Operation Timings

_{Actual operation duration vs pytest total (which includes fixture setup and cold path prerequisites)}

Operation	Actual	Test Total
cold has ready	3µs	99ms
cold create	12.14s	12.42s
warm has ready	3µs	16.26s
warm get session	76µs	13.69s
warm zero db	52µs	8.67s
warm cooldown	74µs	51.89s
expired resync	519µs	9.75s
cold create ws1	8.83s	19.27s
cold create ws2	9.98s	19.27s

✅ Cold / Warm Session Path

_{Session resolution with real PostgreSQL + Daytona sandbox}

Test	Duration	Result
cold path has ready session returns false	99ms	✅
cold path creates initialized session	12.42s	✅
warm path has ready session returns true	16.26s	✅
warm path returns same session object	13.69s	✅
warm path zero db queries	8.67s	✅
sync cooldown respected	51.89s	✅
cooldown expired triggers sync	9.75s	✅
multiple workspaces independent sessions	19.27s	✅

✅ has_ready_session Edge Cases

_{Sync check accuracy for various session states}

Test	Duration	Result
no session cached	3ms	✅
session not initialized	3ms	✅
sandbox none	3ms	✅
sandbox not ready	3ms	✅
full ready state	12.57s	✅

✅ Conditional update_workspace_activity

_{60-second conditional SQL UPDATE behavior}

Test	Duration	Result
first call writes	98ms	✅
immediate second call skips	98ms	✅
nonexistent workspace returns false	94ms	✅
deleted workspace returns false	96ms	✅

Total: 17 tests, 145.02s, 100% pass

---

_{Generated by backend-integration CI}