This looks to be a dev vibecoding their way through "MinIO for Azure" (monetization plans included) and... it does not seem to be going very well?
The whole YOLO-ing signature inputs and storage ops aside, something like this should never pass even cursory code review:
catch (EntityNotFoundException) when (upsert)
It's a red-fag bonanza: 'upsert' is not related to the exception at all (so has no place in an exception filter), no exception details are accessed to begin with, and a new record needing to be created on an upsert does not seem to be an exceptional situation at all?
So, yeah, all they're doing here is adding an 'if' that is literally 100s of times more expensive than a regular function call, which isn't great for a database-ish storage system, where you'd expect concepts like 'indexes' and 'table stats' to come into play.
Not trying to be unnecessarily dismissive or anything, but at this rate, this codebase is not going in the direction that matches the ambitions of the project website.
Hey Edgy, thank you for your input! This is an emulator, not a real storage-like system which is more like a LocalStack for Azure, not "MiniIO for Azure" :) So while some things / patterns may look fishy or hacky, there's a tradeoff between what's considered a performance issue and what is "just doing the work". The codebase is not vibecoded, the project is created by myself for the last 1 year with some AI based assistance. But I will definitely look into some of the red flags you mentioned!
I work on Azure Storage. My team is looking into the SharedKey documentation for Table Service and we will make the documentation around authorization flow clearer for developers. Your post is helpful input for that. Thank you for sharing this.
Thanks! I believe that the main issue was encoding/decoding behaviour for URL between Go and .NET, not the documentation itself, but it's great to hear that such feedback is still valuable to you!
This looks to be a dev vibecoding their way through "MinIO for Azure" (monetization plans included) and... it does not seem to be going very well?
The whole YOLO-ing signature inputs and storage ops aside, something like this should never pass even cursory code review:
It's a red-fag bonanza: 'upsert' is not related to the exception at all (so has no place in an exception filter), no exception details are accessed to begin with, and a new record needing to be created on an upsert does not seem to be an exceptional situation at all?So, yeah, all they're doing here is adding an 'if' that is literally 100s of times more expensive than a regular function call, which isn't great for a database-ish storage system, where you'd expect concepts like 'indexes' and 'table stats' to come into play.
Not trying to be unnecessarily dismissive or anything, but at this rate, this codebase is not going in the direction that matches the ambitions of the project website.
Hey Edgy, thank you for your input! This is an emulator, not a real storage-like system which is more like a LocalStack for Azure, not "MiniIO for Azure" :) So while some things / patterns may look fishy or hacky, there's a tradeoff between what's considered a performance issue and what is "just doing the work". The codebase is not vibecoded, the project is created by myself for the last 1 year with some AI based assistance. But I will definitely look into some of the red flags you mentioned!
I work on Azure Storage. My team is looking into the SharedKey documentation for Table Service and we will make the documentation around authorization flow clearer for developers. Your post is helpful input for that. Thank you for sharing this.
Thanks! I believe that the main issue was encoding/decoding behaviour for URL between Go and .NET, not the documentation itself, but it's great to hear that such feedback is still valuable to you!
> The role of Copilot in the investigation
It would be more helpful to know which model was used, rather than “Copilot.”
Mostly Claude Sonnet 4.6 with VS Code Copilot extension. Tested similar extension for Rider but was not satisfied with results.
[dead]