Dynamo Jira Ticket

Dynamo Jira Ticket

When to use

• Creating a new Jira ticket from a bug report, failing test, or code investigation.
• Refining a vague issue description into a structured, actionable ticket.
• Writing acceptance criteria from a feature request or design discussion.

When not to use

• PR descriptions -- use dynamo-pr-description instead.
• Architecture questions -- use dynamo-onboarding instead.

Inputs expected

A bug description, error log, failing test output, feature request, or code investigation findings.

Output format

A complete Jira ticket body ready to paste, following the canonical template in template.

Workflow

1. Gather evidence first. Before writing, check the codebase for supporting details:
   • For node issues: check the node implementation in src/Libraries/ or src/DynamoCore/.
   • For engine issues: check src/Engine/ProtoCore/ and src/Engine/ProtoScript/.
   • For UI issues: check src/DynamoCoreWpf/ and the relevant view extension.
   • For PublicAPI errors: check PublicAPI.Unshipped.txt / PublicAPI.Shipped.txt in the affected project.
   • For test failures: read the NUnit test output and the relevant test file.
2. Write the ticket using ./assets/template.md in this folder.
3. Review -- ensure every section has concrete, verifiable content. No vague language.

Writing Rules

• Title: short, concrete, behavior-focused. Bad: "Dynamo crash". Good: "DynamoSandbox crashes on startup when global.json specifies missing SDK version".
• Prefer behavior over implementation: describe what the user sees, not internal class names.
• Include evidence: paste error messages, stack traces, screenshots. Trim to relevant lines.
• Separate facts from assumptions: if you're guessing at root cause, say so explicitly.
• Acceptance criteria must be testable: each criterion should be verifiable by running a test or checking a specific behavior.

Ticket Template

Use the canonical template at ./assets/template.md in this folder.

Required sections in each generated ticket:

• Title
• Problem
• Expected Behavior
• Repro Steps
• Impact
• Acceptance Criteria
• Investigation Notes

Example: Good ticket

# [DYN-5678] String.FromObject node returns null for custom Python class instances

## Problem

When a Python Script node returns a custom class instance, passing it to `String.FromObject` produces `null` instead of calling `__str__` or `ToString()`. This breaks downstream string operations.

## Expected Behavior

`String.FromObject` should call the object's `ToString()` method (or Python `__str__`) and return the string representation, consistent with how it handles built-in types.

## Repro Steps

1. Open Dynamo Sandbox
2. Create a Python Script node with: `class Foo:\n  def __str__(self): return "hello"\nOUT = Foo()`
3. Connect output to a `String.FromObject` node
4. Run the graph
5. Expected: `String.FromObject` outputs `"hello"`
6. Actual: `String.FromObject` outputs `null`

## Impact

- **Users affected**: Users with Python-heavy workflows using custom classes
- **Frequency**: Always (deterministic)
- **Severity**: Major (breaks string formatting workflows)

## Acceptance Criteria

- [ ] `String.FromObject` returns `__str__` result for Python objects with `__str__` defined
- [ ] `String.FromObject` returns `ToString()` result for .NET objects with custom `ToString()`
- [ ] NUnit test added in `test/Libraries/CoreNodesTests/StringTests.cs`
- [ ] No regression on built-in types (int, float, list, dict)

## Investigation Notes

- **Relevant files**: `src/Libraries/CoreNodes/String.cs`, `src/Engine/ProtoCore/`
- **Root cause hypothesis**: The engine may be wrapping the Python return value in a way that loses the original type's `ToString()` override