[EPIC] Attach Diagnostic to more errors

Is your feature request related to a problem or challenge?

In #13664 we introduced the Diagnostic type and DataFusionError::Diagnostic. They allow enriching errors with messages meant for consumption by end users of an application built on top of DataFusion, by providing rich information and context that directly references locations in the SQL query. They enable features like:

See datafusion/sql/tests/cases/diagnostic for examples on how to extract and use diagnostics:

datafusion/datafusion/sql/tests/cases/diagnostic.rs

Lines 132 to 140 in d5428b2

    
           #[test] 
        
           fn test_table_not_found() -> Result<()> { 
        
               let query = "SELECT * FROM /*a*/personx/*a*/"; 
        
               let spans = get_spans(query); 
        
               let diag = do_query(query); 
        
               assert_eq!(diag.message, "table 'personx' not found"); 
        
               assert_eq!(diag.span, Some(spans["a"])); 
        
               Ok(()) 
        
           }

In that PR, we only implemented diagnostics for:

Unresolved table references
Unresolved column references (qualified and non)
Non-aggregate expressions missing from GROUP BY clause
Ambiguous column references
Wrong number of columns in set expression (e.g. UNION)
Incompatible types in binary expressions

This issue is about using Diagnostic in more places, and adding related tests to datafusion/sql/tests/cases/diagnostic. We think we should at least implement the following, but suggestions are welcome and encouraged:

Describe the solution you'd like

The implementation should follow the steps of #13664, by calling DataFusionError.with_diagnostic to attach a Diagnostic to an error that is currently being returned. Tests should be added to datafusion/sql/tests/cases/diagnostic for each newly supported scenario.

For some of these items, it might be necessary to enrich the logical types with the Span information coming from the parser. This should be done using the datafusion::common::Spans type (note the "s"), introduced in #13664 to add span information to datafusion::common::Column.

It is desirable that the implementation is as little invasive as possible, in that it shouldn't require changing tons of function calls and types, unless absolutely necessary. The public facing API shouldn't change. The Diagnostic should be attached as soon as possible to the creation of the wrapped DataFusionError (i.e. deep in the call stack) and every error should ideally have just one Diagnostic.

Describe alternatives you've considered

No response

Additional context

No response

Hi, is this still a potential GSoC project? It looks like many of the tickets in this epic have an open pull request and are close to completion. If you know of any other areas that could use some DX improvements, I'd be interested to work on them!

@jsai28

Hey @jsai28! You're right, most of them are being worked on. But just recently I've filed #15276. I was planning on doing it myself but you could take it you'd like :) In that case, let's coordinate on the implementation details 😊

@eliaperantoni

@eliaperantoni Sure, I'll take a look at that! Thanks

Are there any updates on this EPIC? Are we still working on it?

Are there any updates on this EPIC? Are we still working on it?

On my side, unfortunately I no longer have the time to follow the updates on these tickets, or provide guidance, at the moment :/

@eliaperantoni

I've opened a PR for one issue part of this epic. @eliaperantoni if you've no time I can try to lead this epic and resolve issues.

@buraksenn

@buraksenn Absolutely! Feel free to take over this epic :)

@buraksenn

Hi @buraksenn,
Just ran a status update on this epic (as of 2026-10-08), since a lot has moved since the last comment.
Please correct me if I've got anything wrong.

Still open:

Issue	Assignee	PR	Status
#14431 invalid argument types	choplin	#23063 (open)	The current review suggestion is to keep validation in `verify_function_arguments`, use the best available (approximate) span, and defer exact call-site spans to a coordinated major release. Blocker: Probably need a committer to confirm the direction, #14432 and #15276 will likely depend on the same decision
#14432 wrong number of arguments	Chen-Yuan-Lai	none open	#15451 and #15490 were closed as stale in mid-2025. Last activity on the issue is 2025-04.
#14436 duplicate table name	vegarsti, zjregee	none open	#14767, #20720 and #21395 were all closed (the last two as stale). #20720 had review feedback that was not yet addressed.
#15276 UDF `diagnose` / `FnCallSpans`	jsai28	none	No PR found. Last activity is the 2025-04 design discussion.

@buraksenn: you opened #20720. Do you want to reopen it, or are you happy for someone else to pick it up?
I'm happy to help with #14436 or the #14431 follow-up. I'll wait for replies before starting, to avoid duplicating work.

@haochunchang

Hi @buraksenn, Just ran a status update on this epic (as of 2026-10-08), since a lot has moved since the last comment. Please correct me if I've got anything wrong.

Still open:

Issue Assignee PR Status
#14431 invalid argument types choplin #23063 (open) The current review suggestion is to keep validation in verify_function_arguments, use the best available (approximate) span, and defer exact call-site spans to a coordinated major release. Blocker: Probably need a committer to confirm the direction, #14432 and #15276 will likely depend on the same decision
#14432 wrong number of arguments Chen-Yuan-Lai none open #15451 and #15490 were closed as stale in mid-2025. Last activity on the issue is 2025-04.
#14436 duplicate table name vegarsti, zjregee none open #14767, #20720 and #21395 were all closed (the last two as stale). #20720 had review feedback that was not yet addressed.
#15276 UDF diagnose / FnCallSpans jsai28 none No PR found. Last activity is the 2025-04 design discussion.
@buraksenn: you opened #20720. Do you want to reopen it, or are you happy for someone else to pick it up? I'm happy to help with #14436 or the #14431 follow-up. I'll wait for replies before starting, to avoid duplicating work.

Hi @haochunchang, you can pick up if you want thanks for the work

Navigation Menu

Repository navigation

[EPIC] Attach `Diagnostic` to more errors #14429

Is your feature request related to a problem or challenge?

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	#[test]
	fn test_table_not_found() -> Result<()> {
	let query = "SELECT * FROM /a/personx/a/";
	let spans = get_spans(query);
	let diag = do_query(query);
	assert_eq!(diag.message, "table 'personx' not found");
	assert_eq!(diag.span, Some(spans["a"]));
	Ok(())
	}

[EPIC] Attach Diagnostic to more errors #14429

Description

Is your feature request related to a problem or challenge?

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Activity

jsai28 commented on Mar 19, 2025

eliaperantoni commented on Mar 19, 2025

jsai28 commented on Mar 19, 2025

alamb commented on Sep 10, 2025

eliaperantoni commented on Sep 10, 2025

buraksenn commented on Mar 5, 2026

eliaperantoni commented on Mar 5, 2026

haochunchang commented on Oct 8, 2026

buraksenn commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[EPIC] Attach `Diagnostic` to more errors #14429