replace eigen logger

[cody-littley]

Describe your changes and provide context

LittDB originally used an in-house logger from Eigen. We obviously don't want to use the Eigen logger. This PR swaps out the logger for a generic slog.Logger.

Note that LittDB is still not compiling automatically with the remainder of the toolchain. To build these changes, cd to the litt directory and run make build. There are additional third party dependencies to be removed prior to full integration.

[github-actions]

The latest Buf updates on your PR. Results from workflow Buf / buf (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	✅ passed	✅ passed	✅ passed	Apr 30, 2026, 6:46 PM

[bdchatham]

Thinking it would make sense to use seilog instead

https://github.com/sei-protocol/seilog

[cody-littley]

seilog is an implementation of slog. When this is fully integrated with our stack, it will be using a seilog instance. What benefit do we gain by using the more specific type at the call sites?

[cody-littley]

Another consideration. We may eventually want to spin this out into its own repo, potentially for use by outside parties. If we do that, being more generic for the required log framework would be a good thing to do.

[bdchatham]

By "implementation of slog" do you mean that it uses slog?

Our existing sei-chain stack uses seilog throughout, if I'm not mistaken. I can appreciate the goal to make this generally useful but I think it'd be good to focus on making it homogenous in our own stack for now. In the worst case, let a user choose their logger and our own stack will just pick seilog.

Seilog would add continuity with our existing patterns. Two key wins I see over slog are hot-reload for log level and module-scoped log messages.

[cody-littley]

seilog implements the slog interface, meaning that you can still use a slogger at runtime even if the interfaces use type slog.

I'm open to moving to seilog in the future, but I'd like to keep the scope of this PR focused. The focus for this PR was to incrementally move LittDB towards being clean by removing a third party dependency.

Seilog is currently missing a critical feature that will require nontrivial refactoring to support. Specifically, seilog requires me to set environment variables in order to configure it, which means that I can't configure it at boot time like I do a normal slogger. I can work around this, but it requires a complex multi-binary startup sequence (see cryptosim pattern).

[bdchatham]

Makes sense and I'm aligned with using the interface being objectively the right decision.

What ultimately lead me to write that comment was this:

if cfg.LittConfig.Logger == nil { cfg.LittConfig.Logger = slog.Default()

I left the comment on the slog import to broadly discuss how we are injecting our actual log implementation and match existing sei-chain patterns. I now realize I should have been more specific.

If there are feature limitations, can you create a git issue on the seilog package, or wherever it belongs? As long as we're continuously keeping up with a homogenous logging layer over time then I'm happy.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.15%. Comparing base (b8eebf2) to head (fa4943b).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3326      +/-   ##
==========================================
- Coverage   59.17%   59.15%   -0.03%     
==========================================
  Files        2097     2094       -3     
  Lines      172489   171630     -859     
==========================================
- Hits       102075   101522     -553     
+ Misses      61557    61304     -253     
+ Partials     8857     8804      -53     

Flag	Coverage Δ
sei-db	70.41% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 71 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.