bug_report

One bug report from one connection, from the moment its form opens to its receipt.

The incident context is frozen in New(), before anything can yield, and only ever goes to the bridge. Everything after goes through the reporting bridge on this machine, one request at a time per report. The window only updates when something here changes, and we poll only while it is open and the report waits on the service.

Var Details

answered

The window's Try agains that have their answer, from zero each time it opens, which it waits on to say how it went

busy

Whether a reporter's action is running, which holds every other action

capture_next

The next chunk index we take

capture_nonce

Ties a capture's messages to the request that started it

capture_path

Where the capture's base64 is staged

capture_picture

The picture the capture is for

capture_ready

Whether the capture's window has shown its preview, which one whose renderer died never does

capture_received

Base64 characters staged so far

capture_total

The capture's whole base64 length, fixed by its first chunk

capture_ui

The UI that window showed when asked, so a reused window can't answer for it

capture_until

When an unfinished capture gives up

capture_window

The window a capture was asked of

context

What the game looked like when the report was opened, never changed after and never sent to the window

context_saved

Whether the bridge holds our context, which every other call needs

fields

The reporter's text and choices as the page last sent them - the window never asks for incidentAt

fields_dirty

Whether fields changed since the bridge last saved them

fields_epoch

Bumped whenever we replace the page's text, so a page holding older text can't write it back

impacts

How much a bug gets in the way, worst first - the service's severity and its words

kinds

What a report can be about, in the order the window offers them - the service's category, its words and icon

limit_kind

Which hourly limit holds sending, reports or sends, while its wait_time from start_time runs

owner

The connection writing this report

pictures

The report's pictures in the order they were added, or null with none

pictures_made

Pictures made for this report, which numbers the next one's id

poll_delay

The wait before the next background poll, growing while nothing changes

poll_failures

Failed polls in a row, which pause polling at four

polling_paused

Whether polling stopped after failures until the reporter retries

receipt_arrival

When the receipt we hold came, in REALTIMEOFDAY, which its wait to publish again counts from, or 0 when it has no wait

refused

Whether the report server turned down the last bridge request, which status then explains

registered

Whether the reporting service holds our draft, which the bridge registers after it takes our context

remote_draft

A saved draft that moved on while we had unsaved text, waiting for the reporter to choose

rendering

Whether this report is rendering an in-game capture, which holds every report of its connection

request_id

This report's id at the bridge

requesting

Whether a bridge request for this report is in flight

result

The submission's outcome - checking, needs_revision, limited, or accepted with its receipt

revision

The saved draft revision our fields are based on

sealed_results

The outcomes that hold a report's pictures as they are - sent, or being checked

session_id

The connection's session id, frozen into the context

shown

What the window holds, as what each of its keys was made from, so an update sends only the keys that changed - null when we don't know

start_time

When the hourly limit holding sending began, in REALTIMEOFDAY

started_at

The round time the report was started, so Recent bug reports can tell them apart

status

One line telling the reporter what is happening, or null with nothing to say

submission_key

The idempotency key of the submission being checked

unreachable

Whether the last bridge request went unanswered, which the window shows until one gets through

upload_until

Until when BYOND's file prompt may upload one image past the usual upload limit

view_cooldown

Spaces in-game captures, held across every report of the connection

wait_time

How long the hourly limit holds sending from start_time, in deciseconds

Proc Details

adopt_draft

Replaces our text with a saved draft's and sends the page the new text

attachment_call

Runs one attachment operation at the bridge.

The request only ever names files we generated, never a path from the reporter. Arguments:

• operation - upload, preview, remove or consent
• attachment_id - the attachment it acts on, which the bridge checks against the draft's
• body_file - the staged image an upload sends
• output_file - where a preview is saved
• public_consent - for consent, whether the image may go public with the issue
• encoding - base64 when an upload's file holds a capture's base64
• source - for an upload, where the image came from - view, window or file
• wanted_type - for a preview, the image type we'd rather have, which a bridge that can't make it ignores

attachments_wire

The report's pictures as a submission names them, each image's id and whether it may go public

begin_ui_capture

Asks one of the reporter's other TGUI windows for a snapshot of itself.

The window renders it, lets the reporter preview and crop it, then sends it back in small acknowledged chunks that receive_ui_capture() stages. Arguments:

• window_id - which of the reporter's windows, as the page picked it
• replace - the id of the picture it retakes, or null for a new one

begin_view_capture

Renders the reporter's whole view on the server and adds it to the report as a picture.

It's sliced over ticks, so a big view costs the server some time but never stalls it, and it's held to one render a reporter every BUG_REPORT_VIEW_COOLDOWN, whichever report they're in, and BUG_REPORT_RENDERS_MAX across the server. The render spends the captures allowance when it starts, so one dropped on the way still counts. Arguments:

• replace - the id of the picture it retakes, or null for a new one

bridge_action

Runs an action on this report's draft at the bridge, handing it our context first if it doesn't hold it.

Arguments:

• action - read, save, submit or receipt
• extra - more fields for the action's body

bridge_call

Sends one request to the reporting bridge and waits for it.

Returns the decoded reply, the response itself for a reply saved to output_file, or null with status saying why. One request runs per report and BUG_REPORT_MAX_REQUESTS across the server, so nothing a reporter does can pile up rust-g jobs. We skip SShttp on purpose, it would log the bearer token and the report text. Arguments:

• route - the bridge's game route, like action or attachment/preview
• body - the request body as text
• headers - headers besides the bearer token
• body_file - a generated file rust-g sends as the body instead
• output_file - a generated file rust-g saves the reply into
• timeout - seconds rust-g waits for the bridge

bridge_reply

Reads the bridge's answer to one request.

Returns the decoded reply, the response itself for a reply saved to output_file, whose headers say what it holds, or null with status saying why. Only no answer or a 5xx means we couldn't reach the report server. A 4xx is it turning the request down, which sets refused and says why in status, except a conflict, which means the draft moved on. A preview says either on its own card, since the page's line and poll are the draft's and receipt's. Arguments:

• response - the bridge's answer
• output_file - the file rust-g saved the reply into, if any

bring_forward

Brings the report window in front of the reporter's others, returning whether one was open to bring

can_bridge_request

History may check a retained submission without making it the active editable report.

cancel_ui_capture

Ends the capture, telling its window to stop and deleting whatever was staged, and says why.

A new picture goes with it, a retake keeps the image it had. Arguments:

• reason - why it ended, ours (no_answer, expired, closed, interrupted, not_saved) or the window's own

capture_targets

The reporter's other open TGUI windows a capture could be taken of, for the page's picker, or null with none

capture_window_allowed

Whether a window is one of the reporter's own visible TGUIs, and not a bug report

changed_data

The window's keys that changed since it was last sent, or null with none, noting that it holds them now

check_submission

Asks the service how the submission's check is going

choose_screenshot

Lets the reporter pick a screenshot with BYOND's file prompt, then uploads it.

Arguments:

• replace - the id of the picture it replaces, or null for a new one

data_sources

What each of the window's keys is made from, which changes whenever the key does.

The waits and ages in a key count from the update that sent it, so they aren't part of what it's made from.

draft_attachments

The service's pictures in a saved draft, from its list or from an older bridge's one attachment

drop_unix_times

Drops the service's Unix ms times from its answer, keeping the waits beside them.

DM can't hold a Unix ms time exactly, and the window only reads the waits, which we count from now. Returns the answer. Arguments:

• answer - a submission's result or an accepted report's

end_new_image

Ends a picture's new image before the service got it.

A retake goes back to the image it had. A new picture shows why it failed, or goes when there's nothing to show. Arguments:

• picture - the picture whose new image ended
• why - nothing or render for a render that didn't work, null to drop a new picture

expire_ui_capture

Gives up on a capture still unfinished when its time runs out

expire_unready_capture

Gives up on a capture whose window never showed its preview

find_picture

Finds one of the report's pictures by the window's id for it

finish_action

Ends the reporter's action, saying how it went when there's news, and shows the window where things stand.

Arguments:

• message - a new status line, or null to keep the current one
• targets - whether the reporter's other windows go too, as when the one a capture was of may have gone

hold_sending

Holds sending under an hourly limit, which the window shows with the time it lets go.

Arguments:

• kind - reports for accepted reports, sends for submissions
• wait - deciseconds until it lets go

issue_url

Only accepted reports with a GitHub link may launch a browser from either report window.

limit_data

The hourly limit holding sending as the window takes it, with the wait in ms since DM can't hold a Unix ms time

limit_source

What the hourly limit holding sending is made from while it holds, or null once it lets go

load_preview

Fetches a picture's private preview into a data URL, a WebP from a bridge that makes them and a PNG from any other - never browse_rsc, which keeps every image in the player's cache for good

note_retry

Notes when the receipt came, since the wait to publish again it sends is only true the moment it answers

picture_consent

Sets whether a picture may go public with the issue, requiring a preview only when switching back to public.

Arguments:

• picture_id - the window's id for the picture
• public_consent - whether it may go public

picture_data

The report's pictures as the window shows them, or null with none

picture_for

Gets the picture a capture or upload is for - the one it retakes, or a new one if the report has room.

Returns null when there's no such picture to retake or no room, saying so when the reporter can do something about it. A new picture joins the report once its action really starts. Arguments:

• replace - the id of the picture to retake, or null for a new one
• source - where the new image comes from, which a retake keeps

pictures_ready

Whether every picture's image is checked and ready to go with the report

poll

The background poll - waits out anything else talking to the bridge, and stops once the window closes

poll_failed

Counts a failed poll, pausing polling after four in a row until the reporter retries - one turned down still got its answer, whose status says why

prompt_screenshot

Opens BYOND's file prompt with its one-image upload allowance, returning the chosen file

push_update

Sends the window what changed since it was last sent.

Arguments:

• targets - whether the reporter's other windows go too, which the window otherwise asks for when it gets focus

read_draft

Reads the saved draft and its pictures, keeping unsaved text when the saved draft moved on

receipt_wait

How long until the service's next try at the sent report, in deciseconds, or 0 with nothing to wait for

receive_ui_capture

Takes one message of a capture from its window - its preview showing, a chunk to stage, or the reporter cancelling.

Chunks come in order, each acknowledged before the next, and go straight to a file as the base64 they are. We never decode or hold the image. Returns whether the message belonged to the capture. Arguments:

• window - the window the message came from
• type - bug-report/capture-ready, bug-report/capture-chunk or bug-report/capture-cancel
• payload - the message's decoded payload, a cancel's with the window's reason

refresh

Reads whatever this report waits on - its new context, its submission check, its receipt, or its draft and pictures.

Arguments:

• asked - whether the reporter asked with Try again, whose answer the window waits on

refresh_receipt

Fetches the accepted report's receipt, which gains its issue link once published

remove_picture

Removes a picture, giving back its image first.

Arguments:

• picture_id - the window's id for the picture

remove_unclaimed

Gives back every image the service holds that none of our pictures claims, returning whether they all went.

Arguments:

• draft - the saved draft as just read, or null to read it now

render_held

Whether the reporter's in-game captures are held, since one of their reports is rendering or rendered too recently

resolve_draft

Settles a conflict between our unsaved text and a saved draft that moved on.

Arguments:

• keep_local - TRUE keeps our text over the saved draft, FALSE loads the saved draft

result_data

The submission's outcome as the window takes it, with the receipt's wait counted from now

save_context

Hands our frozen context to the bridge, which keeps it before any cloud draft exists

save_fields

Saves the reporter's text to the draft if it changed, returning whether the saved draft now matches it

schedule_poll

Arms the one background poll while the window is open and the report waits on the service.

Arguments:

• restart - poll soon again, since something new just started waiting

send_partial

Sends the window only these keys

send_preview

Answers the window asking for a picture's preview.

We fetch it from the bridge each time and keep no copy, the window keeps it by id and take. Arguments:

• picture_id - the window's id for the picture

show_getting_ready

Says we're getting ready when the bridge takes over a second to take our context

submit_fields

Saves and submits the report, then checks it until the service answers

take_allowance

Spends one of the reporter's hourly allowances, or says how long until one frees up.

Returns whether there was one. Arguments:

• kind - accepted, submits, uploads, captures or saves
• spend - FALSE to only check

took_draft

Notes that the service holds our draft, ending the wait for it

update_local_fields

Takes the page's text and choices, refusing a stale page or text past the service's limits. No network.

Returns whether the page's fields were taken. Arguments:

• incoming - the page's fields
• epoch - the fields_epoch the page's text is based on
• required - whether the title, steps and what should have happened must be filled, as for a submission

update_pictures

Takes the service's view of the draft's pictures, so their checks and sharing catch up.

An image the service holds that we never heard back about goes to a picture whose upload went unconfirmed. A picture whose image the service no longer holds says so. Arguments:

• draft - the saved draft

upload_picture

Uploads a picture's staged image to the bridge and deletes the file, whatever happens.

A retake gives back the picture's last image first, or one a lost reply may have left with the service, so the report never holds more than the service takes. The reporter's own files spend the hourly upload allowance, captures the bigger capture one. Arguments:

• picture - the picture the image is for, already on the report
• path - the generated file holding the image, or a capture's base64
• encoding - base64 for a capture, null for an image file
• spent - whether its allowance was spent already, as an in-game capture's is when its render starts and a file's when the prompt gives it back

valid_owner

Whether this is still the report its connection is writing - a reconnect or another report ends that

waiting_on_service

Whether this report waits on the service for something a poll would bring

window_title

The title a window shows the reporter, for the picker and its picture's caption - its UI's title, or the name of what it's for, never the interface's id