Repository: LMFDB/lmfdb

Issue:
Stop the computation on the fly of L-functions of large coductor/degree
Our servers are struggling today, as bots are going through lovely L-functions like `L/ArtinRepresentation/6.13639404879872.18t319.a.a/`
that are being computed on the fly.

I am unsure where the bots found the link, but we should stop enabling these computations.


Discussion:
I looked into this a bit, and wasn't sure exactly what we wanted to disable.  All Artin L-functions are computed on the fly, right?  So do we want to raise an error for these L-functions, or find some minimal set of precomputations that we can do that makes it feasible for the pages to load?
The only L-functions we should be computing on the fly are those explicitly listed on https://www.lmfdb.org/L/Completeness.  We should display an error whenever someone or something tries to dynamically compute an L-function otherwise.

There is no L-function link on https://www.lmfdb.org/ArtinRepresentation/1.30269.2t1.a.a/, because we do not display L-function links on Artin pages when the conductor dimension product exceeds 729000000000000, see [this line](https://github.com/LMFDB/lmfdb/blob/d884641dc08c8494e118d0e63418b22829733c12/lmfdb/artin_representations/main.py#L390) in the Artin rep code.

The problem is that the bots are somehow finding links to the L-function anyway, so we may need to put a separate check into the L-function code rather than relying on the absence of links (which is annoying, because the bound really depends on the type of L-function, but maybe there is a generic bound on the analytic conductor that we could use as a simpler cutoff.

A better solution would be to permanently disable all dynamically computed L-functions and precompute the L-functions we actually want to show, which has been on our todo list for a long time now.  I could make an argument that we should just disable all dynamic L-function computations now, since this would put more pressure on us to do the precomputations we have been planning to do (for more than 5 years now).  Many of the dynamically computed L-functions with conductors below the cutoff we currently use still put a heavy load on the server (e.g. https://www.lmfdb.org/L/ArtinRepresentation/1.30269.2t1.a.a/)

I'd also like to know where/how bots are finding the link in the OP, we should not be displaying it anywhere.




Resolving patch:
diff --git a/lmfdb/lfunctions/Lfunction.py b/lmfdb/lfunctions/Lfunction.py
--- a/lmfdb/lfunctions/Lfunction.py
+++ b/lmfdb/lfunctions/Lfunction.py
@@ -44,6 +44,8 @@
 )
 import sage.libs.lcalc.lcalc_Lfunction as lc
 
+from lmfdb.app import is_debug_mode
+
 from lmfdb.backend.encoding import Json
 from lmfdb.utils import (
     Downloader,
@@ -1254,6 +1256,12 @@ def __init__(self, **args):
         self.primitive = self.artin.primitive()
         self.degree = self.artin.dimension()
         self.level = self.artin.conductor()
+
+        # disable expensive L-functions, these should not be linked anywhere regardless
+        # this threshold comes from lmfdb/artin_representations/main.py
+        if not is_debug_mode() and self.level**self.degree > 729000000000000:
+            raise ValueError(f'Error constructing L-function for the Artin representation {self.origin_label}, as the conductor/degree is too large.')
+
         self.level_factored = factor(self.level)
         self.mu_fe = self.artin.mu_fe()
         self.nu_fe = self.artin.nu_fe()
@@ -1320,7 +1328,7 @@ def __init__(self, **args):
         # Check for compulsory arguments
         if "t" in args and "family" in args:
             args["label"] = args["family"] + "_" + args["t"]
-        validate_required_args ('Unable to construct hypergeometric motive L-function.', args, 'label')
+        validate_required_args('Unable to construct hypergeometric motive L-function.', args, 'label')
         self._Ltype = "hgmQ"
 
         # Put the arguments into the object dictionary


Test patch: