Open lizhihongTest opened 1 year ago
This optimization is more difficult to do:
Currently, ObjectMapOpEnvType in this.op_envtype used to communicate CYFS Stack with the CYFS protocol, its value is not designed for reading. If you use ObjectMapOpEnvType in the log, readability will be significantly reduced.
For example: will load for path_op_env
will become will load for path
, or will load for single
.
Adding a prefix to the log to optimize readability will only turn it into will load for op_env type path
, or will load for op_env type isolate-path
.
I'm still hesitant to change this
Describe the bug IsolatePath/OpEnvStubSingleOpEnvStub/PathOpEnvStub all use GlobalStateRequestor to send requests, and the logs printed by GlobalStateRequestor should be controlled by parameters instead of randomly printing OpEnv types
[[cyfs-ts-sdk] https://github.com/buckyos/cyfs-ts-sdk/src/sdk/cyfs-lib/root_state/requestor.ts](https://github.com/buckyos/cyfs-ts-sdk/blob/master/src/sdk/cyfs-lib/root_state/request.ts)
To Reproduce For example : IsolatePath/PathOpEnvStub can call this function,why the log just print path_op_env ,This is a bad log, which will cause the user to view the log and cannot distinguish the OpEnv type
Expected behavior OpEnvRequestor can identify the specific OpEnv type through op_envtype, it is recommended to optimize the log
System information [[cyfs-ts-sdk] https://github.com/buckyos/cyfs-ts-sdk/src/sdk/cyfs-lib/root_state/requestor.ts](https://github.com/buckyos/cyfs-ts-sdk/blob/master/src/sdk/cyfs-lib/root_state/request.ts)