Repository navigation
1.0.0 Feature Freeze #291
Description
Activity
Should this #268 be before or after this gets done? I reckon we should release for test usage, and use this epic to organise everything that needs to be done for a 1.0 release.
I reckon we should release for test usage, and use this epic to organise everything that needs to be done for a 1.0 release.
This seems reasonable to me. I'd actually forgotten that we had #268. In that case, perhaps these should all be moved to #268? I was moreso treating this epic as just an interim container for all of the issues that I view as being important to finish up before an initial release, so this can be organised in another way if preferred..
I think this issue can be made into a release version issue. Like
Release 11.0or something. That makes it a feature freeze, and then work out all the final problems/optmisations/bugfixing/code quality issues.Some KeyManager quick fixes:
- Don't need to read from the file when you are always just changing the keys, as it is expected nobody else can swap them around, use the in-memory key which should only be
this._dbKey - Should be using locks to lock the operations on the key renewal, right now race conditions can occur in the side effects there.
- Proper documentation on where subkeys are supposed to be located and managed by who like vault key, db key and session manager key.
- Don't need to read from the file when you are always just changing the keys, as it is expected nobody else can swap them around, use the in-memory key which should only be
The error in:
class ErrorClientInvalidNode extends ErrorClient { exitCode: number = 70; }requires a proper review. It seems weird. Should this really be in
client/errors.ts?I noticed that some exceptions are
Missingand some areNotFound. So far noRequired.We should standardise on which suffix we use to mean these things.
All uses of
failshould be replaced with expectations. Details here: https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/213#note_742208447Should replace all use of
pollin ourtests/utils.tswithsrc/utils.ts. Any timeout usage should be done withtimerStartandtimerStop.Some very rough time estimates for the current state of this epic. Time estimates include planning, research, development, review and testing times:
- Canonicalise node ID representation #261 + Refactor
NodeIdas a proxy/singleton instance #254 (would be done concurrently): 3 days - NAT-Traversal Testing with testnet.polykey.io #159: should be done as part of testnet deployment (have removed from this issue for that reason)
- Fix Concurrent Testing Scalability - Find Blocking Code, Make them Non-Blocking #264: 5 days
- Agent spawning tests require refactoring. #238: will be completed by Implementing BIP39 recovery, Unattended Bootstrap and Agent Start and Status #283
- Optimise the execution time of PK CLI calls by not importing the entire kitchen sink #277: 2 days (should only require some benchmarking, and potential adjustments)
- Investigate and fix random
NodeGraphtest failures #274: 1 day - Support read-after-write consistency for
NodeGraphbucket operations #244: 2 days - Transport Agnostic RPC #249: a fair bit more to consider here, so I'd overestimate at 7-10 days
- Canonicalise node ID representation #261 + Refactor
Mostly all done. We're going to do a testnet deployment in a couple days. Closing this.
- added sub-issues
on Oct 23, 2025
After the testnet deployment, the next stage of development with Polykey should be focusing on tying up the loose ends, such that we can perform our initial release!
We shouldn't be focusing on introducing new features (hence, "feature freeze"), and instead be looking at making the current state of Polykey as robust as possible.
Using this epic primarily as a means of categorising issues that should be a part of this enhancement process.
Template and description TBD