feat: Protect Langchain callbacks

[anticorrelator]

resolves #1615

Shields Langchain instrumentation errors from causing exceptions in user code.

[RogerHYang]

why not make its intent even more clear?

Suggested change

	def _null_fallback(
	serialized: Dict[str, Any],
	messages: List[List[BaseMessage]],
	*,
	run_id: UUID,
	tags: Optional[List[str]] = None,
	parent_run_id: Optional[UUID] = None,
	metadata: Optional[Dict[str, Any]] = None,
	**kwargs: Any,
	) -> None:
	def _null_fallback(*_: Any, **__: Any) -> None:

[anticorrelator]

I don't think of this as a general purpose fallback, just a alternate code path this one specific method. E.g. it doesn't have to actually be a no-op, is this a strong opinion you hold regarding this call signature?

[RogerHYang]

It's not a matter of opinion, but, as you have pointed out, there are two intentions that are subtly different:

1. It doesn't have to be no-op (so it's open to adding more code)
2. It should be no-op (no, don't add anything here)

I understand that 1 applies in the general case, but in this specific instance, 2 is what I think we want, and if that's the case then what I was asking for is to dial up the degree of specificity in what we are communicating here.

Alternatively, If 1 is actually what we want, i.e., letting users develop a separate code path, then we should leave a comment letting developers know that any errors here will not be caught.

Lastly, we can also keep the verbose signature and leave a comment that says "don't add anything" but that is uneconomical because it leaves us with two separate locations for maintaining the call signature (just to keep them in sync) even though one of the locations is always a no-op.

[anticorrelator]

I personally don't believe verbosity or repeated signatures are too onerous to maintain in the sense that I think they should be clearly and directly linked (maybe I should even pick a better name for the fallback function). The function as it looks now is what I intend for this to look and feel like (providing an explicit alternate codepath that has exactly the same usable signature), though I understand if you feel differently.

I'm mostly interested in what you think the shortest resolution might be

[RogerHYang]

That's fine, I guess I reached with the opposite conclusion from reading the code alone, so a few clarifying comments will resolve this.

[anticorrelator]

Sure thing, let me give that a try and if it still feels bad to you I'll move to the generalized signature

[RogerHYang]

I guess it would also have to be renamed to something other than null_fallback