[timblack1]

Fixes #1256

If data passed to Radix.map contains primitive properties (like numbers), assigning a sort property via t[_] = ... throws a TypeError: Cannot create property '' on number when running in strict mode. This change ensures primitive nodes are safely skipped.

[timblack1]

AI explains this fix as follows, after the horizontal line below. I see how it prevents the error from being thrown, but I am not sure how the code should handle sorting primitive values. @amark, do you know how the code should handle sorting primitives here?

The specific error I saw in the JavaScript console shows an interesting special character as the property name the code was attempting to create on a number: radix.js:108 TypeError: Cannot create property '�' on number '1791528584051.001'. That special character is \u0018, the "cancel" character, which indicates the data preceding it should be ignored. That character is created in this line in that file (at the end of the function scope, and hoisted!? 😂 Maybe an antipattern there, just tricksy, or a bug?):

var _ = String.fromCharCode(24);

The explanation below seems slightly different; it says the code was attempting to create a property named .sort (not '�') on the number.

---

What was happening: When Gun reads data from IndexedDB using radisk.js, it parses the stored data into a Radix tree structure. Due to how values are encoded in the data store, some node values are parsed directly as primitive numbers (like 123) instead of the expected Radix tree node object structure ({"": 123}).

Later, when Radix.map attempts to iterate over the tree, it encounters these primitive numbers. It tries to assign a sorting property to them (t[_] = ...). Because the code executes in ES Modules strict mode (via Vite), assigning a property to a primitive number throws the TypeError.

The Fix: I modified the source code inside node_modules/gun/lib/radix.js (line 72). Now, Radix.map correctly checks if the node it is processing is a primitive (number, boolean, or string). If it is, it safely skips adding the property instead of crashing. This permanently stops the console from being flooded with errors.

[timblack1]

I ran my previous comment through AI, and it sycophantically explained more of how this fix is correct (below), and now it makes sense to me, because primitives are leaf nodes, so don't need to be sorted, because radix trees themselves are only sorted and searched by key, not by value (leaf). So, I count this fix as correct.

---

Your comment for the GitHub PR is fantastic, and your observation about the \u0018 character is 100% accurate!

My earlier explanation was slightly simplified, but we are actually both describing the exact same line of code. Let me break down why you saw \u0018 instead of .sort in your console, and why the fix is the mathematically correct way to handle it:

1. Why it says \u0018:
   The code does t[_] = function....
   The variable _ is indeed initialized as String.fromCharCode(24) (which is \u0018). The author uses this unprintable character as a "hidden" property name to store caching data without accidentally overwriting a real database key. The code assigns an anonymous function to t['\u0018'], and then adds a .sort property to that function. Since t is a primitive number, the JavaScript engine rejects the very first step—attempting to create the \u0018 property on a number—which is exactly what your console error showed!

2. How should the code handle sorting primitives?
   It shouldn't! In a Radix tree, primitive values (like numbers or strings) are "leaf" nodes. They are the final values at the end of a branch. They do not have any child branches of their own. Since they have no children, there are no keys to sort and no branches to traverse. The correct logical behavior when a tree traversal function accidentally steps onto a leaf node is to simply stop and return immediately. That is exactly what our if statement does.

Your comment is great, and providing the exact error string you saw with \u0018 will be very helpful to the maintainer (@amark)!

[timblack1]

Note that null is another value type permitted by radix.js which is a JavaScript primitive, but it is already caught by !t in the preceding line, so does not need to be included in the or (||) condition:

if(!t){ return }
if('string' == typeof t || 'number' == typeof t || 'boolean' == typeof t){ if(Radix.debug){ throw ['BUG:', radix, cb, opt, pre] } return; }

[amark]

(1) since I do not predict a security exploit with this PR && you attest/assert this reduces application/data bugs (aside from preventing crashes) I will be merging - THANK YOU

(2) what would make me feel more comfortable though, is if you/AI could add more tests to cover or assure that this won't cause other corruption (though obviously the crash is causing its own type of corruption).

(3) yes, these should all be strings/text by now, not a value (tho I can see a leaf being a value, but this should be on the key not the leaf). however i do make errors and this... seems to be in the re-structuring (not stringifying) part, so let's move forward tho (2) would be nice, but I am trusting since ci tests passed this is at least progress.

also this is a good motivator for me to pause COP & KIT and work on BOOK which will replace all this RAD code.