{ "number": 33847, "repo": "bitcoin/bitcoin", "url": "https://github.com/bitcoin/bitcoin/pull/33847", "title": "kernel: Improve logging API", "author": "ryanofsky", "author_association": "MEMBER", "created_at": "2025-11-10T23:30:46Z", "updated_at": "2026-09-15T13:41:33Z", "age_days": 310, "draft": true, "labels": [ "Validation", "Needs rebase" ], "milestone": null, "base": "master", "head_sha": "6d370c720a4c106968e73cba67888efb2d7fbb88", "head_ref": "pr/klog", "head_repo": "ryanofsky/bitcoin", "head_history": [ { "t": "2025-11-11T14:25:12Z", "sha": "0926479924f453c38b5e0ad069435fb3241b2389" }, { "t": "2025-12-12T12:19:34Z", "sha": "168128bb5e69b10a29732d5af0719adabbb776e1" }, { "t": "2026-01-18T16:59:01Z", "sha": "c8f6a474f9bcc72b08e67101aba0962ba66af1aa" }, { "t": "2026-01-22T22:32:09Z", "sha": "6d370c720a4c106968e73cba67888efb2d7fbb88" } ], "additions": 118, "deletions": 108, "changed_files": 5, "commit_count": 1, "size_bucket": "M", "mergeable_state": "dirty", "bot": { "drahtbot": { "present": true, "reviews": { "concept_ack": [ { "login": "sedited", "url": "https://github.com/bitcoin/bitcoin/pull/33847#issuecomment-3517090033" }, { "login": "stickies-v", "url": "https://github.com/bitcoin/bitcoin/pull/33847#issuecomment-3532938522" } ] }, "conflicts": [ { "number": 36207, "title": "kernel: add wtxid accessor", "author": "KY-U" }, { "number": 36197, "title": "kernel: Replace application log callbacks with file logging", "author": "w0xlt" }, { "number": 35322, "title": "logging: streamline Logger state and drop redundant methods", "author": "ryanofsky" }, { "number": 34775, "title": "kernel: make logging callback global", "author": "stickies-v" }, { "number": 34374, "title": "kernel: use struct-based logging and simplify logging interface", "author": "stickies-v" }, { "number": 30342, "title": "kernel, logging: Pass Logger instances to kernel objects", "author": "ryanofsky" } ] } }, "acks_parsed": { "sedited": { "kind": "concept_ack", "hash": null, "t": "2025-11-11T14:05:55Z", "stale": false }, "stickies-v": { "kind": "concept_ack", "hash": null, "t": "2025-11-14T13:59:36Z", "stale": false } }, "acks_tally": { "ack": 0, "stale_ack": 0, "concept_ack": 2, "approach_ack": 0, "nack": 0, "concept_nack": 0, "approach_nack": 0 }, "reviews": { "approved": 0, "changes_requested": 0, "distinct_reviewers": [ "sedited", "stickies-v", "stringintech" ] }, "signals": { "needs_rebase": true, "ci_failed": false, "mergeable_state": "dirty", "last_author_activity": "2026-01-22T22:32:09Z", "last_reviewer_activity": "2025-12-10T16:40:55Z", "last_reviewer": "stickies-v", "author_silent_days": 237, "waiting_on_author_days": 0, "days_since_update": 2 }, "refs": { "mentioned": [ 30342, 30595, 31650, 33728 ], "depends_on": [], "fixes": [], "linked_issues": [], "references": [ { "number": 30342, "type": "pull", "state": "open", "merged": false, "merged_at": null, "title": "kernel, logging: Pass Logger instances to kernel objects" }, { "number": 30595, "type": "pull", "state": "closed", "merged": true, "merged_at": "2025-11-04", "title": "kernel: Introduce C header API" }, { "number": 31650, "type": "pull", "state": "closed", "merged": true, "merged_at": "2026-01-19", "title": "refactor: Avoid copies by using const references or by move-construction" }, { "number": 33728, "type": "pull", "state": "closed", "merged": true, "merged_at": "2026-01-14", "title": "test: Add bitcoin-chainstate test for assumeutxo functionality" } ], "conflicts": [ 36207, 36197, 35322, 34775, 34374, 30342 ] }, "stack": { "shares_commits_with": [], "based_on": [], "base_for": [] }, "review_paths": [ "src/kernel/bitcoinkernel.h" ], "body": "Simplify kernel logging API and try to connect it to the rest of the kernel API by letting log options be set on `Logger` objects directly and `Logger` objects to be associated with `Context` objects directly. Also drop `logging_disable()` function and avoid having library accumulate log messages in a 1MB buffer by default.\n\nChanges are intended to make the API a little less surprising and more future proof. Rationale is described in some more detail the commit message.\n\nThis change is not backwards compatible but I'd expect it to port over pretty smoothly to the language bindings, and offer the same benefits for them as for C/C++ callers.", "commits": [ { "sha": "6d370c720a4c106968e73cba67888efb2d7fbb88", "date": "2026-01-22T16:20:43Z", "message": "kernel: Simplify logging API\n\nCurrent kernel logging API is too complicated and too restrictive. This PR\ntries to improves it.\n\nI'd expect an API that supported logging to allow creating log streams with\ndifferent options and providing some way to specify which library operations\nshould be logged to which streams.\n\nBy contrast, the current API allows creating multiple log streams, but all the\nstreams receive the same messages because options can only be set globally and\nthe stream objects can't be passed to any kernel API functions. They are not\neven referenced by the `btck_Context` struct which holds other shared state. If\nno log streams are created, log messages are generated anyway, but they are\nstored in a 1MB buffer and not sent anywhere, unless a log stream is created\nlater, at which point they are sent in bulk to that stream. More log streams\ncan be created after that, but they only receive new messages, not the buffered\nones. If log output is not needed, a btck_logging_disable() call is required to\nprevent log messages from accumulating in the 1MB buffer. Calling this will\nabort the program if any log streams were created before it was called, and\nalso abort the program if any new log streams are created later.\n\nNone of these behaviors seem necessary or ideal, and it would be better to\nprovide a simpler logging API that allows creating a log stream, setting\noptions on it, registering it with the `btck_Context` instance and receiving\nlog messages from it. Another advantage of this approach is that it could allow\n(with #30342) different log streams to be used for different purposes, which\nwould be not be possible with the current interface." } ], "timeline": [ { "t": "2025-11-11T14:05:55Z", "kind": "comment", "who": "sedited", "assoc": "MEMBER", "text": "Concept ACK\n\nThank you for contributing this @ryanofsky! We've discussed doing something similar a few months ago. This is close to how I hoped to implement the logging capabilities, but reviewers highlighted some inconsistencies with this approach: A secondary logger object cannot receive its own non-global options. The docstrings do at least still explain this even with this change, I am not sure if it is really less surprising for users. Maybe it would be preferable to push forward #30342 before this is done? Tagging @stringintech and @stickies-v here, since they both left comments on the logging capabilities during review of #30595." }, { "t": "2025-11-11T14:25:12Z", "kind": "force_push", "who": "ryanofsky", "commit": "0926479924f453c38b5e0ad069435fb3241b2389" }, { "t": "2025-11-11T14:28:09Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "Updated d0bd114e974500ad11c8ecac26d6606166ab7438 -> 0926479924f453c38b5e0ad069435fb3241b2389 ([`pr/klog.1`](https://github.com/ryanofsky/bitcoin/commits/pr/klog.1) -> [`pr/klog.2`](https://github.com/ryanofsky/bitcoin/commits/pr/klog.2), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/klog.1..pr/klog.2)) updating btck_logging_connection_create documentation\n\nRebased 0926479924f453c38b5e0ad069435fb3241b2389 -> 168128bb5e69b10a29732d5af0719adabbb776e1 ([`pr/klog.2`](https://github.com/ryanofsky/bitcoin/commits/pr/klog.2) -> [`pr/klog.3`](https://github.com/ryanofsky/bitcoin/commits/pr/klog.3), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/klog.2-rebase..pr/klog.3))\n\nRebased 168128bb5e69b10a29732d5af0719adabbb776e1 -> c8f6a474f9bcc72b08e67101aba0962ba66af1aa ([`pr/klog.3`](https://github.com/ryanofsky/bitcoin/commits/pr/klog.3) -> [`pr/klog.4`](https://github.com/ryanofsky/bitcoin/commits/pr/klog.4), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/klog.3-rebase..pr/klog.4)) due to conflict with #33728\n\nRebased c8f6a474f9bcc72b08e67101aba0962ba66af1aa -> 6d370c720a4c106968e73cba67888efb2d7fbb88 ([`pr/klog.4`](https://github.com/ryanofsky/bitcoin/commits/pr/klog.4) -> [`pr/klog.5`](https://github.com/ryanofsky/bitcoin/commits/pr/klog.5), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/klog.4-rebase..pr/klog.5)) due to conflict with #31650" }, { "t": "2025-11-11T15:29:27Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "re: https://github.com/bitcoin/bitcoin/pull/33847#issuecomment-3517090033\n\nThanks @TheCharlatan. I think the approach you took in #30595 of making the kernel API mirror the current `logging.h` API was the best one to take as a starting point. #30595 covers a large surface area, and it would have been asking too much of reviewers to evaluate all the different ways the kernel API and existing APIs could or should diverge in one PR. It should be more manageable to make kernel API improvements in targeted followups like this PR, and hopefully the improvements here are welcome.\n\nOn the question of whether to push forward with this PR or #30342 first: I think this PR should have much higher priority than #30342. The reason is that this PR is not backwards compatible and will require downstream changes to language bindings and probably to most external programs using those bindings. By contrast, #30342 is backwards compatible. If #30342 were merged later, it would just improve how requested log options are applied and how log messages are forwarded, without requiring external changes. #30342 is also a bigger PR that will take more effort to review.\n\nIt is true that a potential drawback of merging this PR without #30342 is that the design of the API exposed here could make it seem like it provides more functionality than it currently does. Users would not know about the limitations without reading the documentation, and could be surprised or confused. I just would not expect this to be a problem in practice, because the surprising behavior should only occur if users create multiple log streams or multiple kernel context objects at the same time, and that should be uncommon. And even if it did happen, the consequences would not seem very bad: log options might be applied in a different way than expected, or some log messages might be received unexpectedly. It seems like it would place a bigger burden on users to first roll out a logging API that does not support multiple options and streams and then later change it incompatibly, than to roll out an API that could support them and then implement that support internally later." }, { "t": "2025-11-13T22:07:01Z", "kind": "comment", "who": "stringintech", "assoc": "CONTRIBUTOR", "text": "Thanks @ryanofsky for explaining the trade-offs!\n\nI think I also prefer we push this change after we support separate logger instances per connection though, and at this point keep the API consistent with what it's currently capable of. I'm not sure how big of an impact delaying this would have on bindings/users, especially if we're assuming their use cases are mostly limited to a single logging connection." }, { "t": "2025-11-14T01:29:35Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "Thanks for the feedback @stringintech. Can you explain what specifically you may be looking for which this PR does not provide? The API defined here is consistent and logical. It just happens to be compatible with new features like per-connection options and separate log streams (already implemented in #30342) instead of being pointlessly incompatible with them. It also eliminates the btck_logging_disable() function which is unsafe and confusing. And it gets rid of the kernel's inefficient default behavior of storing up log messages in a 1MB buffer in case a logger is attached at later time, instead taking a simpler and more rational approach: logging when a logger is attached and not logging otherwise. I think if you look at the API and documentation defined here you will see that it makes more sense than the current API and should be less confusing. If there are any specific problems I'd be happy to address them.\n\nIf the logging API is not going to be rationalized soon (it's only been around a week since the API was introduced in #30595), I am concerned it will be more difficult to rationalize later. Logging is a fundamental part of the kernel API so if backwards incompatible changes are made, they are likely to break most language bindings and potentially many applications written in different languages. It should make sense to provide a logging API that's forward compatible and exposes fewer quirks and implementation details sooner instead of later, if we can do that." }, { "t": "2025-11-14T12:58:20Z", "kind": "comment", "who": "stringintech", "assoc": "CONTRIBUTOR", "text": "By inconsistency, I mean that refactoring `set_options`/`set_level_category`/`enable_category`/etc. to receive a `btck_LoggingConnection*` parameter suggests that settings are supported per connection, while calling them on a newly instantiated logging connection would actually override settings for all previously instantiated connections. While the actual behavior is well-documented, the function signatures themselves may still create expectations of per-connection isolation.\n\nI understand you already acknowledged this concern in your [last paragraph here](https://github.com/bitcoin/bitcoin/pull/33847#issuecomment-3517459399), and believe the benefits of pushing this change forward outweigh this downside. My preference was to wait for #30342, since the API refactoring and implementation naturally seem to be parts of a single patch, though I may be too optimistic about how much time/effort it takes to push that PR forward, or the effort it takes to adapt the bindings/other projects to the breaking changes.\n\nRegarding the `StartLogging()` call being moved from the logging connection constructor to context creation: This delay could mean logs won't be produced by context-free operations (like `btck_script_pubkey_verify()`). If i am not wrong, it appears we don't currently have such operations producing logs, but if we add them in the future while still using a global logger, would we need to move `StartLogging()` back to the logging connection constructor?" }, { "t": "2025-11-14T13:59:36Z", "kind": "comment", "who": "stickies-v", "assoc": "MEMBER", "text": "Concept ACK for making the logging interface local instead of global, but approach ~0 leaning towards nack. I think the approach that merging the backwards-incompatible interface early is not unreasonable but not my preferred one, because:\n- I don't think we should at all care about breaking the kernel interface at the moment, the kernel API is experimental and upstream development flexibility and pace should absolutely be prioritized until kernel is in a more stable state\n- having the interface behave in unexpected ways is just not desirable, even if this gap is not catastrophic as I think you correctly described\n- internal logging refactorings / changes (e.g. #30342, but also others) may surface roadblocks or ideas that inform us about a better interface design, so waiting a bit more seems helpful to me\n\nI would prefer to convert this to draft, and have this PR serve as the WIP discussion grounds for polishing up the kernel logging API while we make changes such as #30342. I don't have a proposal ready, but I would also like to make breaking changes to the category/level/enable/disable logic (at least for kernel API) which I think currently is extremely unergonomic and unintuitive, as well as support richer callbacks that do not require users (language bindings, especially) to parse already formatted log strings." }, { "t": "2025-11-14T14:15:54Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "[quoted text omitted]\n\nThanks, I'll look into this. I am a little surprised there would be any context-free operations except very basic ones that shouldn't log. It'd expect there to be some context object, even a minimal one, associated with all non-trivial operations to control things like logging, random number generation, caching, etc.\n\nOf course I do understand your abstract concern that adding a connection parameter \"suggests that settings are supported per connection.\" This is similar to how in many filesystem API's, flushing one file can cause other files to be flushed to disk. Or how in the python database API, cursor objects have commit() and rollback() methods even though in some implementations calling these can affect other cursors. It's not unusual for APIs to provide a little more generality than is guaranteed in every case, if this provides other benefits and avoids other types of pain.\n\nSo I would like to understand any ways your abstract concern could translate to confusion or problems in practice. When I consider all use-cases I can think of, the new logging API here is less confusing and more coherent than the current one. I already mentioned the current nonsensical default behavior of storing all log messages into a 1MB buffer even when no logging is requested. But lets say you do want to enable logging. You might see the current `btck_logging_set_*` functions and think they actually do something. Well, they don't, because in order to have logging, you need to create a connection object. Adding a connection parameter to these functions makes it obvious that a connection object is actually necessary. Or, in the current API you might see the `btck_logging_connection_create` function and notice that takes a callback and returns a `btck_LoggingConnection` handle. But where is that handle used? Only by the `btck_logging_connection_destroy` function and nowhere else. In the current API, kernel functions which actually log and set logging options are less discoverable because the API is not coherent and the functions using the connection do not reference it.\n\nMore generally, I'd expect the majority of scripts and applications using the kernel library to only set one logging callback, and in that use-case, the new API should be a strict improvement over the old one. It is true that in the alternate case where an application does create multiple log callbacks, if the application calls `btck_logging_set_*` functions, and the author did not read the documentation for those functions, they might mistakenly think those options apply to a single callback instead of multiple. But those applications will still benefit from this PR because of the follow-up in #30342 which can apply log options singly. So I am trying to think of any application or use-case which would not benefit from this PR and I don't see one. Would be interested to know if I am looking at this from the wrong perspective or am missing something." }, { "t": "2025-11-14T14:33:29Z", "kind": "comment", "who": "ryanofsky", "assoc": "MEMBER", "text": "[quoted text omitted]\n\nSure happy to do that while there is conceptual discussion.\n\n[quoted text omitted]\nI think I've pointed out practical ways the current interface behaves in unexpected ways and is counterintuitive, and practical ways this PR is an improvement. The concerns you and stringintech raised do seem plausible, but also vague so if there are any concrete scenarios you can think of where this PR might create a problem, they would be helpful to know about.\n\nThanks for the thoughtful reviews!" }, { "t": "2025-12-10T13:20:45Z", "kind": "review_comment", "who": "stickies-v", "assoc": "MEMBER", "path": "src/kernel/bitcoinkernel.h", "commit": "6d370c720a4c106968e73cba67888efb2d7fbb88", "in_reply_to": null, "text": "How do we deal with ownership of the `logger` here? Is it owned by the context? If yes:\n- should we still expose the `logging_connection_destroy` function?\n- how do users update the logging_connection options? Their handle should be invalid after ownership is passed to the context? A `btck_context_get_logger()` could be an alternative?\n- users may need to create multiple logging connections, e.g. to pass to context-free functions that need logging\n\nIf no:\n- managing lifetimes becomes more brittle, i.e. users must ensure `logger` is kept alive for the duration of `context`. This feels like a terrible idea, but one approach could be to let the static `kernel::Context` own the loggers, with the implication that connections can be created, but not destroyed (until the application aborts)?" }, { "t": "2025-12-10T14:27:00Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/kernel/bitcoinkernel.h", "commit": "6d370c720a4c106968e73cba67888efb2d7fbb88", "in_reply_to": 2606640746, "text": "Thanks for following up! If I understanding your concerns correctly, I don't think there is any reason to think this PR can cause problems.\n\nIn the kernel API, log messages are only written to logging connections, not to files or other possible log sinks. So with #30342 a \"logger\" is just a logging connection. If you create a logging connection, you create a `BCLog::Logger` instance and if you destroy the logging connection you destroy it.\n\nBefore #30342, there is only a single `BCLog::Logger` instance and all logging connections share it. This PR does not change that. It keeps behavior the same and just adds function parameters so the association between log connections and log sources is explicit, rather than that implicit, and so the more flexible logging enabled by #30342 can be introduced without API changes, binding changes, script and application changes.\n\n[quoted text omitted]\nIt is owned by the logging connection.\n\n[quoted text omitted]\nNo.\n\n[quoted text omitted]\nYes.\n\n[quoted text omitted]\nNo, a logging connection is just a handle referring to a BCLog::Logger instance. The handle can be used until the connection is closed.\n\n[quoted text omitted]\nNo, a logging connection can be passed to different log sources, the log sources do not own the connection.\n\n[quoted text omitted]\nNo, they only need to keep the logging connection open as long as they want to receive logging callbacks. If they don't want to receive logging callbacks, there is no need for a connection or logger.\n\n[quoted text omitted]\nThis sounds very kludgy and there should be no need for it. (Having a static context in general seems like a kludge to me and I hope there are plans to get rid of it. There should definitely be no need to use it here.)" }, { "t": "2025-12-10T14:49:17Z", "kind": "review_comment", "who": "stickies-v", "assoc": "MEMBER", "path": "src/kernel/bitcoinkernel.h", "commit": "6d370c720a4c106968e73cba67888efb2d7fbb88", "in_reply_to": 2606640746, "text": "I agree that with the current implementation (where `btck_LoggingConnection` just represents a callback) there are no meaningful lifetime concerns, except perhaps conceptually. However, with something like #30342, it does look problematic, since `Context` would be [keeping a reference](https://github.com/bitcoin/bitcoin/pull/30342/files#diff-cc28221ef8d0c7294dda4e3df9f70bb6c062006b387468380c2c2cc02b6762c3R372) to the logger instance, which may have already been invalidated by the user (who owns the logger)?\n\nAssume the following pseudo-code:\n\n```\nopts = btck_context_options_create();\nlogger = btck_logging_connection_create();\nbtck_context_options_set_logger(opts, logger);\nctx = btck_context_create(opts);\nbtck_logging_connection_destroy(loger);\n```\n\nI think `ctx` is now in an invalid state? We had a similar concern in earlier versions of this PR, where context had to be kept alive for the duration of chainman, so eventually the approach was changed to let chainman own the context it was created with. Arguably, the same could be done here, as per the bullet points under the \"yes\" section? It's currently my preferred approach over passing just a view (which, I think should be passed by const reference and documented as such, if you decide to keep it).\n\nIn my previous comment, in the context-owns-logger approach, I suggested we might want to remove `logging_connection_destroy`. Of course, if/when we have context-free functions that need logging, it would be perfectly fine to pass a stand-alone `btck_LoggingConnection`, at which point exposing `logging_connection_destroy` would make sense again." }, { "t": "2025-12-10T15:50:01Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/kernel/bitcoinkernel.h", "commit": "6d370c720a4c106968e73cba67888efb2d7fbb88", "in_reply_to": 2606640746, "text": "I see comment has been edited, but just to respond to the example, since it is illustrative:\n\n[quoted text omitted]\nI'd want to resolve this by adding a `int use_count` field to the `LoggingConnection` struct and making the `btck_logging_connection_destroy` call fail if the use_count is not 0.\n\nI would imagine using a similar pattern in other parts of the kernel when references to handles need to be stored.\n\nI don't think it would be smart in general to work around the need to share handles by resorting to using global variables or large context objects, or by limiting flexibility of the API." }, { "t": "2025-12-10T16:40:55Z", "kind": "review_comment", "who": "stickies-v", "assoc": "MEMBER", "path": "src/kernel/bitcoinkernel.h", "commit": "6d370c720a4c106968e73cba67888efb2d7fbb88", "in_reply_to": 2606640746, "text": "I was actually wrong about my earlier example about chainman owning context: it is [passed](https://github.com/bitcoin/bitcoin/blob/56ce78d5f62c9eb9353d33eedd15495c1205465f/src/kernel/bitcoinkernel.h#L967) as a non-owning (`const` ptr) view, and lifetime then ensured via [`std::shared_ptr`](https://github.com/bitcoin/bitcoin/blob/56ce78d5f62c9eb9353d33eedd15495c1205465f/src/kernel/bitcoinkernel.cpp#L472). Whether we prevent destroying or automatically extend lifetimes is not really my concern here, so I think we can wrap this up on the conclusion that you prefer letting the user manage `btck_LoggingConnection`'s lifetime (with safeguards in place), which I think works well.\n\nThank you for the in-depth response. Essentially, the misunderstanding I had is that if the context doesn't own the logging connection it can't ensure its lifetime. I now understand that's not actually true, and we already use this pattern in existing kernel code, e.g. with context associating with chainman. I agree then that there is no need for context to own the logging connection." }, { "t": "2025-12-10T18:59:16Z", "kind": "review_comment", "who": "ryanofsky", "assoc": "MEMBER", "path": "src/kernel/bitcoinkernel.h", "commit": "6d370c720a4c106968e73cba67888efb2d7fbb88", "in_reply_to": 2606640746, "text": "re: https://github.com/bitcoin/bitcoin/pull/33847#discussion_r2607414440\n\n[quoted text omitted]\nThat's pretty interesting. I can see how the lifetime extension idea also works, although my first reaction is that it seems a little fragile, and it seems safer in general to return an error to applications if they try to delete objects that are currently in use, instead of internally giving the objects longer lifetimes.\n\nIn the case of `btck_LoggingConnection`, I agree either approach could work. The only nuance is that if a shared_ptr is used, regardless of whether the logger object is freed, `btck_logging_connection_destroy` needs to unregister the logging callback function so the kernel does not try to call the application after it is no longer expecting calls." }, { "t": "2025-12-12T12:19:34Z", "kind": "force_push", "who": "ryanofsky", "commit": "168128bb5e69b10a29732d5af0719adabbb776e1" }, { "t": "2026-01-18T16:59:01Z", "kind": "force_push", "who": "ryanofsky", "commit": "c8f6a474f9bcc72b08e67101aba0962ba66af1aa" }, { "t": "2026-01-22T22:32:09Z", "kind": "force_push", "who": "ryanofsky", "commit": "6d370c720a4c106968e73cba67888efb2d7fbb88" } ], "labels_log": [ { "t": "2025-11-11T12:27:57Z", "action": "labeled", "label": "Insufficient Review", "who": "maflcko" }, { "t": "2025-11-11T12:28:03Z", "action": "unlabeled", "label": "Insufficient Review", "who": "maflcko" }, { "t": "2025-11-11T12:28:12Z", "action": "labeled", "label": "Validation", "who": "DrahtBot" }, { "t": "2026-01-14T23:12:17Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-01-18T18:08:55Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-01-19T12:03:20Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-01-23T00:30:57Z", "action": "unlabeled", "label": "Needs rebase", "who": "DrahtBot" }, { "t": "2026-09-15T13:41:32Z", "action": "labeled", "label": "Needs rebase", "who": "DrahtBot" } ], "state_log": [ { "t": "2025-11-14T14:32:52Z", "kind": "convert_to_draft", "who": "ryanofsky" } ], "text_chars": 21358, "text_tokens_estimate": 5339, "changed_paths": [ "src/bitcoin-chainstate.cpp", "src/kernel/bitcoinkernel.cpp", "src/kernel/bitcoinkernel.h", "src/kernel/bitcoinkernel_wrapper.h", "src/test/kernel/test_kernel.cpp" ], "files": [ { "path": "src/bitcoin-chainstate.cpp", "add": 2, "del": 2 }, { "path": "src/kernel/bitcoinkernel.cpp", "add": 44, "del": 40 }, { "path": "src/kernel/bitcoinkernel.h", "add": 32, "del": 30 }, { "path": "src/kernel/bitcoinkernel_wrapper.h", "add": 31, "del": 26 }, { "path": "src/test/kernel/test_kernel.cpp", "add": 9, "del": 10 } ], "test_lines": 19, "git": { "head": "6d370c720a4c106968e73cba67888efb2d7fbb88", "head_matches_backup": true, "base": "1d8cb78d5b1c2cfa4bafa6a225693ced69e47c64", "commits": [ { "sha": "6d370c720a", "subject": "kernel: Simplify logging API", "files": 5, "add": 118, "del": 108 } ], "patch_truncated": false }, "input_hash": "423c9363d6bd8a68", "extracted_at": "2026-09-17T16:15:31+00:00" }