Recently I've started seeing a transient error <5% when I build my applications.
Specifically pdc will return the following:
error: Metadata bundle ID not in reverse DNS format (ex: com.panic.b360)
The command I'm using to build is: pdc src/main.lua "playdate-playpaint.pdx"
If I immediately re-run the build (with no changes) everything works as expected.
It was triggered when I changed my bundleID from net.notpeter.playpaint to the shorter net.playpaint. The issue is never triggered if I use the old three level domain and regularly with the two-level domain. If that is an invalid domain I'd expect it to be caught every time, but instead there's obviously something non-deterministic in the check and I thought y'all might like to know.
I created a small script and am able to consistently reproduce with both SDK 2.0.0 and 2.0.1:
set -e
date
pdc --version
COUNTER=0
while true
do
echo -n "$COUNTER, "
pdc src/main.lua "playdate-playpaint.pdx"
let COUNTER=COUNTER+1
done
That's totally bizarre. I haven't had any luck reproducing it using your pdx and script posted above. And that error message shows up pretty early in the compilation process so there's not much happening before that could be messing things up. One thing that's a little unusual is you're pointing pdc at the main.lua file instead of the folder. Does it still happen if you do pdc src playdate-playpaint.pdx instead?
Here's the test I was running, just ftr: pdctest.zip (1.2 KB)
Thanks @dave for taking the time to dig into this, I appreciate it.
I can confirm the issue does occur even when I point pdc at the directory (pdc src playdate-paint.pdx). Your minimal zip is sufficient to consistently reproduce the issue for me. I'm running MacOS 13.4.1 (a) on an MacBoo Pro 16-inch (2019 Intel). I don't see it under linux.
Aha, @dan found it, classic buffer overrun: We're expecting the bundleID to have two dots, and when it doesn't we read past the end. In that case, whether it passes the validateBundleID() function depends on what's in memory after that string. I'm surprised it doesn't fail more often!
We'll fix that overrun, and using a three-part bundleID will work around that now. I'm not sure yet whether we'll require three-part ids or allow two-parters--it's possible the server component requires three.
