i'd like us to record sync failures in a more robust way. the reason for doing so, rather than/in addition to simply watchdog()-ing, is so that we can perform analytics in order to determine repository health. in fact, the best approach might simply to be to have the table record all syncs, successful or failed, so that we can establish a success % for any given repository.

there's no need to link this to the events table. it can, and should, keep its own timestamps, and just generally be a standalone thing.

Comments

sdboyer’s picture

sdboyer commented

there is now a particularly clear place for this to fit in with some of my most recent changes on sync-tinkering. see VersioncontrolRepository::sync() - there's even comments for 'logging'. yeah, that's where this goes.

sdboyer’s picture

sdboyer commented
Title: Add a special logging table for recording sync (failures) » Implement a synclogger plugin
Status: Active » Needs work

i've added a basic synclogging table, {versioncontrol_sync_log}, which has a largely complete set of fields on it. however, it's clear that there's a fair bit of functionality here, and i'd like to encapsulate it into a plugin that handles both CRUD and some analytics, so that it can easily be swapped out if users want to cache in an alternate location. or something. this being a fairly separate codepath and nontrivial undertaking, though, i've put it on a separate branch to avoid mucking things up.

that can happen in the longer term. this immediate commit at least ensures the data is being stored, though it provides no methods for accessing the data once inserted. consequently, it is without tests that ensure all the right data is being stored. it's just an extra insert & update on sync, though, so i think it's pretty harmless to allow in as-is and expand more on later.

sdboyer’s picture

sdboyer commented

i changed my mind - the initial version of this was on sync-tinkering, and did get merged in directly to mainline. now the required work is now making it a plugin. that'll mean making another standard interface for it too, of course.

sdboyer’s picture

sdboyer commented
Version: 6.x-2.x-dev » 7.x-1.x-dev
Status: Needs work » Postponed
Issue tags: +vc-next

the system we have right now really works pretty well. i'm pretty confident that what we have right now would work cross-backend (should that day ever come), and all of the data that it captures would be applicable in all backend situations. the only use case for making it a plugin is alternate data storage, sending to splunk, things like that. nothing we have any immediate need for.

so, this is postponed AND vc-next.