feat: show Record Origin under the Snapchat conversation bubble - #1091
Merged
Conversation
Declares extraColumns on the arroyo.db messages conversation view, so every bubble carries Live or Recovered without the examiner having to know the column picker exists. That closes the last gap from #1053: the provenance was visible in the table and invisible in the chat view, which is exactly where a recovered row could be misread as a live message. Record Origin alone rather than all three. It is populated on every row, so every bubble gets a marker, while Recovery Method and Recovery Location stay one click away in the picker and would only add noise under a live message. Depends on LAVA PR #166 (feat/convo-extras), which introduces the field. Alexis confirmed shipping ahead of that merge is fine. Verified rather than assumed, since an unrecognised declarative option fails open silently: - The literal `extraColumns` exists in the consumer, read at conversationExtras.js:104. It is not on LAVA main yet. - Ran James's actual resolver against the manifest this artifact produces: "Record Origin" resolves to `record_origin`, a real column in the artifact table. - Ran current LAVA main's translation logic against the same manifest. The array coerces to a string via JS key lookup, nothing reads it, no throw, and all required layout fields still resolve. So the field is inert rather than harmful until #166 lands. - The resolver is tolerant either way: display name "Record Origin" and sanitized "record_origin" both resolve correctly, so it keeps working if lavafuncs later learns to sanitize this key like the others. - Record Origin is not one of the layout columns, which the view ignores. Counts unchanged: 16 message rows, 5 conversation rows on hc_pixel8pro_a17. 765 plugins load with no duplicate names. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
One line on the arroyo.db messages conversation view:
Every bubble now carries
LiveorRecoveredwithout the examiner having to know the column picker exists. That closes the last gap from #1053: the provenance was visible in the table and invisible in the chat view, which is exactly where a recovered row could be misread as a live message.Record Originalone rather than all three. It is populated on every row, so every bubble gets a marker, whileRecovery MethodandRecovery Locationstay one click away in the picker and would only add noise under a live message.Dependency
Needs LAVA PR #166 (
feat/convo-extras), which introducesextraColumns. It is not on LAVAmainyet. Alexis confirmed shipping ahead of that merge is fine.Verified, not assumed
An unrecognised declarative option fails open silently, so this got checked properly rather than eyeballed:
conversationExtras.js:104,conversationParams?.extraColumnsmain?"Record Origin"→record_origin, a real column in the artifact tablemainagainst the same manifest"Record Origin"and sanitized"record_origin"both resolve, so it surviveslavafuncslater sanitizing this key like the othersSo the field is inert rather than harmful on current LAVA, and correct once #166 lands.
Worth noting for James:
lavafuncssanitizes the otherdata_viewscolumn values to snake_case before writing the manifest but passesextraColumnsthrough as the display name. It works because the resolver checks the reverse map first, and it keeps working if that changes, but the asymmetry is there.Validation
Corpus
hc_pixel8pro_a17: 16 message rows and 5 conversation rows, unchanged. 765 plugins load with no duplicate names.check_claim_language.pyclean,check_html_safety.pyclean, pylint 10.00/10,lint_changed.pyno new warnings.Co-Authored-By: Claude Opus 5 noreply@anthropic.com