Add output_packet to PodResult

[guzman-raphael]

Feature

• Fix Add output_packet to Pod Result #89

Housekeeping

• Create an alias for Packet.
• Rename Status -> PodStatus to give a clear distinction once we introduce PipelineStatus.
• Rename RunInfo -> PodRunInfo to give a clear distinction once we introduce PipelineRunInfo.
• Box external errors to reduce size of OrcaError.
• Clean up EventMetadata and remove event_classifier from start_service(..).
• Make agent regex more flexible.
• Remove print to console from agent client log(..).
• Simplify store regex.

Docs

• Update some intra-doc links.

Tests

• Use separate network namespace for some error tests.
• Stream console output when running tests with VSCode inline test GUI.
• Add note about reusing cache when running tests with coverage i.e. build faster.

[codecov]

Codecov Report

❌ Patch coverage is 94.17476% with 6 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/uniffi/model/pod.rs	88.88%	4 Missing ⚠️
src/uniffi/orchestrator/agent.rs	66.66%	2 Missing ⚠️

📢 Thoughts on this report? Let us know!

[Synicix]

• Box external errors to reduce size of OrcaError. -> I thought we decided to force everything to be below the box requirement limit of clippy?

• Rename RunInfo -> PodRunInfo to give a clear distinction once we introduce PipelineRunInfo. -> We got rid of PipelineRunInfo entirely and merge it with PipelineRun. The user will get a hash to access to talk to the runner.

[guzman-raphael]

Box external errors to reduce size of OrcaError. -> I thought we decided to force everything to be below the box requirement limit of clippy?

I spent some more time on this since it came up elsewhere. Turns out that the clippy suggestion is actually a good one and it is about understanding how memory is allocated to the stack for enums. Basically, by using box for external errors, we cap out the memory per variant to a pointer to the heap which is just 8 bytes which overall should reduce the memory of our OrcaError for most cases . Here's an example on rust playground that demonstrates what I mean.

Rename RunInfo -> PodRunInfo to give a clear distinction once we introduce PipelineRunInfo. -> We got rid of PipelineRunInfo entirely and merge it with PipelineRun. The user will get a hash to access to talk to the runner.

I was doing some more thinking on this and there is a distinction we should make that we can use PipelineRunInfo for. Internally, we can still keep all the pipeline run data together like we discussed but offer 2 modes for user to access it: static vs dynamic.

Static being the data that doesn't change for the life of the pipeline run (e.g. assigned_name, created time, etc.). These would be acceptable to return in a PipelineRun.

Dynamic being the data that changes while it is progressing (e.g. node states, terminated time, packets completed per node, etc.). This is where we can do something similar to the orchestrator (perhaps agent_client.get_pipeline_info(pipeline_run)) to grab the state at a specific point in time. Therefore, I see value now in using PipelineRunInfo for that.

In summary, PipelineRun and PipelineRunInfo are each subsets of a complete pipeline run in memory. Perhaps the internal type that stores it all can be called PipelineRunState or TrackedPipelineRun.

[Synicix]

Looks good