List one account's most recent LinkedIn message threads, read live from LinkedIn in a browser session on the worker (it queues behind other browser work, so it can take a while). Each row has the other participant (participantName, participantProfileUrl, participantProfileId = their ACoAA… member id), lastActivityAt, unreadCount, the latest message text (lastMessageText), weOweReply (true when THEY spoke last), addressable (false for sponsored/InMail blasts, which carry no participant identity and cannot be replied to) and, when we track that person, `ours` (our status, outcome, campaign). It sends nothing and changes no contact, message or conversation record (the read only notes the account's own member id, so threads between your own accounts can be recognised).
FILTERS. onlyNeedsReply=true keeps threads where they spoke last; onlyAddressable=true drops the blasts; sinceDays and profileUrl narrow further. The walk pages by cursor until `limit` threads pass THOSE filters, the inbox ends, or a page ceiling is hit. With onlyNeedsReply the server then ALSO drops, and counts: threads somebody already decided about after their last message — handled, completed, outcome-marked or snoozed (`alreadyDecidedCount`; a newer message from them brings the thread back flagged `reopened`); threads with your own team's accounts (`excludedInternalCount`); LinkedIn itself — blasts and "The LinkedIn Team" (`excludedSystemCount`); and threads reviewed with li_mark_reviewed and unchanged since (`alreadyReviewedCount`). Those drops happen AFTER `limit`, so a page can hold fewer rows than asked. A lookup that fails filters NOTHING and says so (`decidedLookupFailed`, `internalLookupFailed`, `reviewLookupFailed`). Somebody we hold no record for is untracked, not decided, and stays listed until a mark records them (li_mark_outcome / li_mark_reply_handled / li_snooze_reply accept the participantProfileUrl and create a light record).
COVERAGE. Check `reachedEnd` and `truncated` before concluding anyone is absent: a walk that stopped early has not seen older threads. participantProfileId is the member id li_send_bulk_messages takes for its fast path. Pair with li_read_conversation for a full thread. Seen status is NOT here (it would cost one extra call per thread); stored reads carry it — see li_conversation_history (`seenByThemAt`).