would this return an empty object "frontiers": {} / "representatives": {} if each passed account results in an error?

would this return an empty object "frontiers": {} / "representatives": {} if each passed account results in an error?

checked this, is is returning an empty string when the frontiers or representatives are empty.

checked this, is is returning an empty string when the frontiers or representatives are empty.

can't check accounts_representatives as most public nodes prohibit that action, but accounts_frontiers seems to return an empty string on V23.3 nodes (pre V24 breaking changes) for valid account addresses that don't have any known to node transactions yet (this is the most common scenario)

{  
    "action": "accounts_frontiers",  
    "accounts": ["nano_1hrts7hcoozxccnffoq9hqhngnn9jz783usapejm57ejtqcyz9dpso1bibuy"]  
}

{
    "frontiers": ""
}

with this in mind, I have no idea which option would be the least breaking for existing implementations. this cursed javascript code works because it iterates characters of the string rather than keys of the set:

const response = {
   frontiers: '',
}

for(const accountID in response.frontiers) {
  console.log(accountID)
}

the one below doesn't seem to produce any errors either, but that might be different in other programming languages, so it depends if the implementations check for the presence of field frontiers and/or its type

const response = {}

for(const accountID in response.frontiers) {
  console.log(accountID)
}

accounts_balances doesn't have an issue of similar importance, as the most common scenario (valid account but no seen transactions) provides balance values of 0. that RPC only provides questionable output if invalid addresses are passed. by questionable I mean the V23.3 response is

{
     "error": "Bad account number"
}

and #4228 proposes changing it to

{
    "errors": {
        "nano_36uccgpjzhjsdbj44wm1y5hyz8gefx3wjpp1jircxt84nopxkxti5bzq1rnz": "Bad account number"
    }
}

which is different, but likely fine for an improper configuration error that shouldn't occur on production code (?)