Profile My skills Saved Collections Edit profile Submit a skill

← all publishers

xtdb

@xtdb source repo

6 published skills

  1. ▌
    Jstack · xtdb
    Capture and analyse a Java thread dump from XTDB — deadlocks, blocked threads, lock contention, exhausted pools. Read this when a test run or a node hangs, a Gradle worker stops making progress, or a thread dump needs interpreting. Covers capturing off a running GradleWorkerMain and delegating the parse so the dump stays out of the main context.
    0
    installs
  2. ▌
    Xtdb Git · xtdb
    XTDB's branch-level git practices — why history stays linear, what a rebase conflict actually risks and how to resolve one safely, and the three ways a branch gets merged back to main. Read this before rebasing a branch, resolving a conflict, or merging a branch into main in this repo.
    0
    installs
  3. ▌
    Arrow Leaks · xtdb
    Track down an Arrow "Memory was leaked" error in XTDB — enabling the debug allocator to get the allocation site, the failure-path cleanup gaps that cause most of them, and why property-test shrinking misattributes them. Read this when a test or a node reports leaked Arrow memory.
    0
    installs
  4. ▌
    Xtdb Github · xtdb
    XTDB-specific conventions for issues, PRs and the 2.x project board — what goes on the board, sub-issue parenting, the two tests a milestone has to pass, what to read and which edits to make when picking up a card, the cached project and field IDs, and driving all of it through chalk. Read this before opening an issue or PR, adding a card, setting a milestone or label, or picking up a card in this repo.
    0
    installs
  5. ▌
    Xtdb Testing · xtdb
    XTDB-specific rules and mechanics for running tests — running the task yourself, delegating the failure text, the mid-run edit freeze, test tasks and filters, iteration counts, simulation-test coverage, diagnosing failures, and regenerating arrow-edn golden fixtures. Read this before running or delegating any test run in this repo.
    0
    installs
  6. ▌
    Xtdb Object Boundaries · xtdb
    Where a piece of state or behaviour belongs, and which object owns it. Read this when planning a change; when deciding which type holds some state, whether two fields are one value, whether something is one object or two, or where a method goes; when adding or moving a class, interface, object or namespace; when adding a field that outlives a single call, or a coroutine scope; when splitting a type up or merging two; when threading a value through a new parameter; on a `Map<Id, State>` sitting beside the objects it identifies, or a field only set in some states; and when reviewing a diff that does any of those.
    0
    installs