It seems adding the view recreation is required on both migrations, because otherwise sqlc would not generate the Task structure withDisplayName on up. AFAIU, since our queries all usetasks_with_status view and not thetasks table, PostgreSQL doesn't automatically update the view definition. That is why we need to force PostgreSQL to re-expand thetasks.* wildcard and pick up the new column. Let me know if there is a cleaner way of doing this.

Unfortunately this is the way ™️

We need to get this implemented in our sqlc fork:Emyrk/sqlc#1

Did you hit the limit of 24? I'm not entirely sure what this limit should be but just want to make sure we're not at risk of running over

Yeah, I hit the limit with 24 😕 the JSON would be incomplete and parsing would fail. I bumped it to 50 after testing with the maximum characters we could generate.

According toAnthropic's documentation, Claude uses approximately 3.5 characters per token for English text. Our max output is:

• Base JSON structure: {"task_name":"","display_name":""} = 43 chars
• Task name: 27 chars max
• Display name: 64 chars max
• Total: 134 characters ≈ 38 tokens

So, I guess 50 tokens gives us a comfortable buffer above the theoretical max, accounting for tokenization variance and any extra whitespace Claude might add 🤷‍♀️

@DanielleMaywood How did you come up with 24 the first time? 🤔
I can add these calculations as a comment if that helps

I used one of those tools that tells you how many tokens are in a message, added a few for leeway and doubled it

I tested the max output with anthropics token counting API:https://platform.claude.com/docs/en/build-with-claude/token-counting#count-tokens-in-basic-messages
It seems this endpoint is for input messages, but I assume the tokenization should be identical for both input and output. The endpoint returned 70 tokens, so I've updated this to be 100 for a safety buffer:39d3805

This behavior will be a bit weird if the user specifies a name. There's two options as I see it:

1. Allow them to manually specify it in the request
2. Always generate name/display name, only assign name if empty.

Good catch, I completely missed that! I've updated the code to allow setting a display name as well. Now if either field is not provided, we generate both and use the generated value for the missing field. Addressed in:75277dc

If we don't make a change to the logic above, it also applies to tasks created with a predefined name.