Description:
When a tailcall server is configured without a resolver at the root level, it starts successfully. However, it doesn't respond to any requests, which can be misleading for developers. This behavior should be addressed by enforcing the presence of a resolver at compile time.
Reproduction Steps:
- Configure the tailcall server without a root-level resolver.
- Start the server.
- Observe that the server starts successfully without errors.
- Make a request to the server.
- Notice the server provides no response.
Example Configuration with Issue:
type Query {
user: [User]! # Unresolved root level configuration
}
type User {
id: ID
name: String
posts: [Post] @http(path: "/posts/{{value.id}}")
}
Proposed Solution:
If a configuration lacks a resolver at the root level and none can be inferred, a compile-time error should be thrown, clearly indicating the absence of a necessary resolver. This ensures that developers are aware of the missing resolver before runtime.
Update 1
This should only be applicable for scenarios where the type of the field is required. In a scenario where the field is not required, it's totally fine if there are no resolvers.
Description:
When a tailcall server is configured without a resolver at the root level, it starts successfully. However, it doesn't respond to any requests, which can be misleading for developers. This behavior should be addressed by enforcing the presence of a resolver at compile time.
Reproduction Steps:
Example Configuration with Issue:
Proposed Solution:
If a configuration lacks a resolver at the root level and none can be inferred, a compile-time error should be thrown, clearly indicating the absence of a necessary resolver. This ensures that developers are aware of the missing resolver before runtime.
Update 1
This should only be applicable for scenarios where the type of the field is required. In a scenario where the field is not required, it's totally fine if there are no resolvers.