Not signed in (Sign In)

Not signed in

Want to take part in these discussions? Sign in if you have an account, or apply for one below

  • Sign in using OpenID

Site Tag Cloud

2-category 2-category-theory abelian-categories adjoint algebra algebraic algebraic-geometry algebraic-topology analysis analytic-geometry arithmetic arithmetic-geometry book bundles calculus categorical categories category category-theory chern-weil-theory cohesion cohesive-homotopy-type-theory cohomology colimits combinatorics complex complex-geometry computable-mathematics computer-science constructive cosmology deformation-theory descent diagrams differential differential-cohomology differential-equations differential-geometry digraphs duality elliptic-cohomology enriched fibration foundation foundations functional-analysis functor gauge-theory gebra geometric-quantization geometry graph graphs gravity grothendieck group group-theory harmonic-analysis higher higher-algebra higher-category-theory higher-differential-geometry higher-geometry higher-lie-theory higher-topos-theory homological homological-algebra homotopy homotopy-theory homotopy-type-theory index-theory integration integration-theory internal-categories k-theory lie-theory limits linear linear-algebra locale localization logic mathematics measure measure-theory modal modal-logic model model-category-theory monad monads monoidal monoidal-category-theory morphism motives motivic-cohomology nlab noncommutative noncommutative-geometry number-theory of operads operator operator-algebra order-theory pages pasting philosophy physics pro-object probability probability-theory quantization quantum quantum-field quantum-field-theory quantum-mechanics quantum-physics quantum-theory question representation representation-theory riemannian-geometry scheme schemes set set-theory sheaf simplicial space spin-geometry stable-homotopy-theory stack string string-theory superalgebra supergeometry svg symplectic-geometry synthetic-differential-geometry terminology theory topology topos topos-theory tqft type type-theory universal variational-calculus

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

Welcome to nForum
If you want to take part in these discussions either sign in now (if you have an account), apply for one now (if you don't).
  1. I am about to deploy an attempted fix for the bug we have seen where edits are sometimes lost when a validation error occurs. Some disruption may temporarily be experienced when editing; please save all edits before submitting. I will update when done.

    • CommentRowNumber2.
    • CommentAuthorRichard Williamson
    • CommentTimeSep 9th 2018
    • (edited Sep 9th 2018)

    All should be fine now. In particular, one should never lose an edit or page creation now if a validation error occurs.

    For those interested, the old bug here was that it was attempted to pass in the new edit as a query parameter in the URL. This did not work if the new edit was over a certain size. Now, for some bizarre reason, one of the developers of Instiki (I do not know, and it doesn’t matter, who) realised this (there was a comment in the source code), but decided not fix it properly, but instead just return the old page content.

    The way it works now is that the last submitted edit is saved, and a boolean query parameter is passed indicating whether or not the edit failed; if it did fail, the saved edit is put in the edit pane.

    There is a possibility of a race condition occurring, but given Instiki’s locking functionality this should only occur in exceedingly rare circumstances, so that I don’t think it is worth addressing, for now at least.

  2. Maybe this, though, is an opportunity to say that I would recommend to always save a non-trivial edit before submitting. Even with the best designed web application in the world, there is always the possibility that someone will pull the plug on your internet connection, or that some other unforeseen event occurs. Adding some kind of draft functionality to the nLab would mitigate this to some extent, but never completely.

    • CommentRowNumber4.
    • CommentAuthorMike Shulman
    • CommentTimeSep 9th 2018
    • (edited Sep 9th 2018)

    This is not a criticism, but I’m amused that in #2 you noted that some other past developer noticed a bug but didn’t fix it, and then in your last paragraph noticed another potential bug yourself but didn’t fix it. (-:

    • CommentRowNumber5.
    • CommentAuthorRichard Williamson
    • CommentTimeSep 9th 2018
    • (edited Sep 9th 2018)
    Hehe, indeed! Just for the record, the big difference between the two is how likely they are to occur. The one that was fixed was something which obviously is problematic, and will always occur in certain circumstances. It was moreover, if not trivial, certainly straightforward to fix (took me half an hour or so); the harder part is noticing the cause of it, which the developer had done, but then addressed it in a way which was really hardly better than just letting the error perpetuate. The one I mentioned, on the other hand, is extremely unlikely to occur, whilst a fix would add considerable complexity, and would be likely to cause more problems than it addressed. I mentioned it just for completeness and in case an issue with it should crop up, because race conditions can be very hard to spot.