Vessel.profileData should return null when profiling is disabled #36
Comments
tndhagedorn
added a commit
to tndhagedorn/vessel
that referenced
this issue
Aug 18, 2023
If profiling is disabled, profileData should return null
malachid
pushed a commit
that referenced
this issue
Aug 23, 2023
* Add more error handling and recovery to preload() An instance of a type stored in Vessel may be un-serializable when the definition of that type changes. This can occur when a type's definition is changed but an instance of that type stored in Vessel is not removed or migrated. The `preload()` and `preloadBlocking` APIs can now recover from this state and continue to preload any remaining valid data. `preload()`/`prealoadBlocking()` now return the result of the preload operation - which errors ocurred (if any), and if the preload timeout was hit. Since this is an API change, this is also a breaking change. For completeness this same reporting has been added to the profiling data. * Cleanup Adding license headers, ensuring these are at top of file Clean up some comments and spacing * Remove some unnecessary temporaries * Fix issue #36 If profiling is disabled, profileData should return null * Review comments Updated CHANGELOG and README Remove an unnecessary cursor close Some syntax cleanup * Set correct copyright date on new files * Fixing typo in README.md
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This currently returns the data from the internal
DummyProfilerused when profiling is disabled.This results in profile data consisting of all zeros for every metric with no way to determine from the profile data alone whether profiling was enabled or not.
The text was updated successfully, but these errors were encountered: