| Rev |
Age |
Author |
Path |
Log message |
Diff |
| 37505 |
1 m |
ranu |
/trunk/ |
rbm drr dashboard , all today po rbm view maped |
|
| 37504 |
51 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/transaction/invoicing/ |
Stop invoice read paths creating directories (AccessDeniedException 500s)
getInvoicePath called Files.createDirectories, and getInvoiceFile called it on every
download. Invoices are generated by the cron app as root, so /SaholicInvoices/<month>
is 755 root-owned; a download served by Tomcat cannot create a retailer subdirectory
and threw AccessDeniedException.
It threw on line 1 of getInvoiceFile, before the Files.exists check, so the
ProfitMandiBusinessException on the next line was unreachable and the callers'
deliberate 404 handler ("Invoice not yet generated, please retry shortly") never ran.
Downloads for a not-yet-generated invoice 500ed instead of 404ing - the exact log
noise that handler was added to remove.
Split the path computation out: resolveInvoicePath is side-effect free and used by
getInvoiceFile; getInvoicePath keeps the mkdir for the two generation callers
(InvoiceService:558, GstProService:952). The legacy relocation branch creates the
target directory only when there is actually a file to move.
No ops change needed - generation as root already works. |
|
| 37503 |
1 h 15 m |
ranu |
/trunk/profitmandi-cron/src/main/java/com/smartdukaan/cron/ |
sales target and achievement added cron and flags |
|
| 37502 |
1 h 18 m |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/model/ |
sales target and achievement added cron and flags |
|
| 37501 |
1 h 24 m |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/integrations/icicilombard/model/ |
sales target and achievement added cron and flags |
|
| 37500 |
1 h 31 m |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/ |
sales target and achievement added cron and flags |
|
| 37499 |
1 h 41 m |
ranu |
/trunk/ |
sales target and achievement added cron and flags |
|
| 37498 |
1 h 55 m |
amit |
/trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/ |
Fix: namespace document-level handlers in remaining vm fragments
Completes the sweep started in r37493/r37494. These fragments are injected
with .html(), which re-executes their inline <script>, so every load stacked
another $(document) delegated handler. Mutating handlers then fired N
identical requests and were rejected as duplicates; read-only ones silently
fired N GETs (never deduped, so no alert - just N times the load).
35 fragments, 70 bindings. Adopts the create-purchase-return.vm convention:
one $(document).off('.ns') before the first binding, every event namespaced,
so only the newest binding survives a re-injection.
Notes:
- ticket.vm binds via jQuery(document).on, which the earlier passes did not
match, and its clear must sit OUTSIDE ready() - that callback fires async,
so an inside-ready clear would wipe the top-level binds registered before it.
- agreement-esign-panel, full-stock-payment-panel and create-purchase-return
were left alone; they already clear their handlers (selector-targeted
.off('click', sel) and .off('.createpr') respectively).
Behaviour-preserving: every diff line is either a namespace suffix on an
event string or a new off() call. Selectors, handlers and ordering untouched.
Verified no unprotected document-level bindings remain in any fragment. |
|
| 37497 |
1 h 59 m |
ranu |
/trunk/ |
rbm drr dashboard , all today po rbm view maped |
|
| 37496 |
2 h 8 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/repository/ |
Handle empty IN collections instead of failing the query
An empty IN list rendered as "in ()" (invalid SQL) or threw, in three inconsistent ways:
SQLGrammarException from prepareInPredicate, RuntimeException from prepareEqualPredicate,
and ProfitMandiBusinessException from selectAllByInOrderByDesc. A partner with no activity
for a brand legitimately produces an empty set, so these were 500ing on valid input
(~436 errors/week, mostly V2FofoSchemeController.getBrandWiseIncome).
An empty IN matches nothing: route every IN site through inPredicateOrNone, which returns
an empty disjunction. Empty NOT IN excludes nothing, so it matches everything (conjunction).
selectAllByInOrderByDesc returns an empty list without a DB round-trip.
Also covers three sites that had no guard at all: selectAllByInEqualOrderBysDesc,
selectCountByIn and mapToPredicate. Public API unchanged. |
|
| 37495 |
2 h 8 m |
amit |
/trunk/profitmandi-web/src/main/resources/META-INF/ |
Fix Pine Labs affordability prod config: drop placeholder pinelabs.api.* overrides
r36839 re-added pinelabs.api.base.url/client.id/client.secret to the web module with
REPLACE_WITH_* values, reintroducing the duplication removed in r35832. AppConfig loads
shared-prod first and the module file second, so these shadowed the real credentials and
every affordability call failed with UnknownHostException on plural.v2.pinepg.in
(NXDOMAIN) - 1,254 errors in one week. Removing them restores the working values from
shared-prod.properties (api.pluralpay.in).
pinelabs.account.* deliberately left in place: the web module pins merchant 11467 while
shared-prod has 356460, so removing those would switch the live payment merchant. |
|
| 37494 |
2 h 15 m |
amit |
/trunk/profitmandi-fofo/src/main/webapp/WEB-INF/views/ftl/ |
Fix: namespace document-level handlers in re-injected vm fragments
Same defect class as r37493. These fragments are injected with .html(),
which re-executes their inline <script>, so every load stacked another
$(document) delegated handler. One click then fired N identical requests;
PostInterceptor claimed the first and rejected the rest as duplicates.
Confirmed in prod today: beat-plan-day-view #avSubmit produced bursts of
3-4 rejections on POST /beatPlan/assignVisit/submit. The other four are the
same shape - chart-filter-lms, franchisee-account-creation and beat-plan-bulk
re-inject themselves directly, placement-plan-details does so indirectly by
clicking .search-partner-stock after createPo.
Adopt the create-purchase-return.vm convention: one $(document).off('.ns')
before the first binding, every event namespaced. Only the newest binding
survives, which also fixes handlers holding a stale Velocity closure from a
previously rendered record.
Behaviour-preserving: the only changes are the namespace suffix on 22 event
strings plus the five off() calls. Selectors, handlers and ordering untouched.
Read-only self-injecting fragments (activation-tabular, catalog,
partner-onboarding-*, etc) still stack handlers but only fire GETs, which are
never deduped - left for a separate pass. |
|
| 37493 |
4 h 54 m |
amit |
/trunk/profitmandi-fofo/src/main/ |
Fix: scheme item inline date edit fired N duplicate PUTs per click
scheme-details.vm is injected with .html(), which re-executes its inline
<script>, and a successful save re-injects it - so each load stacked another
$(document) handler for .edit/.cancel/.save-item-dates. One Save click then
fired N identical PUT /scheme/item/window, and PostInterceptor rejected all
but the first with 'Duplicate request.' (27 per click in prod today).
The stacked copies also carried a stale $scheme closure, so a save could
repaint the container with a previously viewed scheme.
Move the handlers to scheme.js (loaded once via include-scripts.vm) and read
the scheme id/window from data- attributes on the fragment root, keeping them
stateless. Fragment is now markup only.
Reuse cleanup while in here:
- configureMultiselect() replaces 3 near-identical multiselect configs
- loadBrandsByCategory/loadCatalogDescriptionByBrands take an optional
afterRender so the add-item modal reuses them instead of duplicating both
- toggleItemDateEdit()/initSingleDatePicker() collapse mirrored blocks
- SCHEME_DETAILS_CONTAINER single-sources the container id
- drop the template's duplicate toIsoDateTime (scheme.js already had it)
- updateSchemeItemWindow() now prefixes context like every other call
Bump jsVersion 409 -> 410. |
|
| 37492 |
5 h 13 m |
amit |
/trunk/ |
errors: wire the GlitchTip appender into cron and fofo logging
Completes r37491, which committed only web's log4j2.xml. cron's and fofo's were
held back because they carried local development log paths -- a user.home
expansion in cron and an absolute /Users path in fofo. Neither can ship: /Users
does not exist on the server, so fofo logging would fail to open its file and
the Alloy stream tailing /var/log/tomcat7/fofo/fofo.log would go dead.
Both files are restored to their production paths and carry the Sentry appender.
Whoever needs the local override should re-apply it locally rather than
committing it. |
|
| 37491 |
5 h 27 m |
amit |
/trunk/ |
errors: ship ERROR events to GlitchTip via the log4j2 Sentry appender
io.sentry:sentry-log4j2:7.22.6 in all three deployables. Pinned to 7.x because
8.x drops Java 8; verified class major version 52.
minimumEventLevel=ERROR is load-bearing. It only became safe after r37490 moved
business validations to WARN -- 32% of the ERROR stream was HTTP 400s where the
user is simply told what to fix, and sending those would have made "insufficient
balance" the top issue and buried real bugs. Breadcrumbs come from INFO so an
issue arrives with the log lines that preceded it.
Attached to the application loggers only; framework noise is not our bug.
web's log4j2.xml is committed here. cron's and fofo's are held back: both carry
uncommitted local development paths (a user.home expansion, and an absolute
/Users path) that would break production logging and the Alloy log tailing.
Their Sentry blocks are staged locally and should land with whoever owns those
path edits. |
|
| 37490 |
5 h 30 m |
amit |
/trunk/ |
errors: separate business, integration and bug -- three failures logged three ways
Everything was logged identically: ERROR, titled 'Internal Server Error', and in
web stack-traced twice (log4j2 plus printStackTrace, the second copy landing in
catalina.out). A partner mistyping an IMEI produced the same output as a
NullPointerException.
That makes the error stream unalertable. Measured over six hours across web and
fofo: 909 ERROR lines, of which 294 (32%) were ProfitMandiBusinessException --
HTTP 400s where the user is simply told what to fix. Any rule on ERROR rate
fires constantly, and an error tracker would rank 'insufficient balance' as the
top issue.
business WARN, no stack trace, 4xx -- expected, user-correctable
integration ERROR + dependency name -- ours is fine, theirs is not
anything else ERROR + stack trace, 500 -- a bug
New IntegrationException carries getDependency(), so two hundred failures of one
gateway group as one problem rather than two hundred unrelated traces. That
category did not exist: such failures were previously either a bare Exception
(indistinguishable from our own bug) or a business exception (which wrongly
blames the user).
printStackTrace removed from the web handler -- it was writing a second copy of
every trace to catalina.out.
Prerequisite for wiring the GlitchTip appender, which must not be attached until
ERROR means something. |
|
| 37489 |
22 h 16 m |
amit |
/trunk/profitmandi-common/src/main/java/com/spice/profitmandi/common/util/ |
Restore Utils.html and Utils.htmlJson removed by r37477
r37477 reorganised Utils while consolidating the mail APIs and dropped its only two
instance methods. They have no Java callers -- they exist solely for Velocity, where
AppConfig binds new Utils() as $vmUtils -- so the compiler, IDE find-usages and any
grep over *.java all reported them dead.
With htmlJson gone, data-paramslist="$vmUtils.htmlJson(...)" stopped rendering usable
JSON on every report link (admin.vm:840, admin.vm:910, reports.vm:51). reports.js:7
then read $(this).data("paramslist") as undefined and returned true, letting the
browser follow the plain <a href> natively -- a GET against the @PostMapping
/reports/{projectName}/{fileName} (ReportsController:126), answered with GE_1007
"Request method 'GET' not supported". The modal POST path was the only way that
endpoint was ever reachable, so every partner report broke at once.
Confirmed against prod: zero occurrences in fofo.log for Aug 13/20/26/28/30, and 87
today starting 18:37:23, right after today's ROOT.war deploy. 13 distinct reports hit.
$vmUtils.html had two further callers that also come back:
offer_margin_detail_partner.vm:12 and :241 (offer description and notes).
Restored verbatim from r37476, and commented as template-only so the next refactor
does not read them as dead code again. |
|
| 37488 |
23 h 0 m |
ranu |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/dao/model/ |
rbm drr dashboard , all today po rbm view maped |
|
| 37487 |
23 h 1 m |
ranu |
/trunk/ |
rbm drr dashboard , all today po rbm view maped |
|
| 37486 |
23 h 18 m |
amit |
/trunk/profitmandi-dao/src/main/java/com/spice/profitmandi/service/mail/ |
mail: fix prod outage -- MailOutboxService must not implement MailQueue
r37478 added 'implements MailQueue' to MailOutboxService. That took down both
ROOT.war and profitmandi-web.war on the 18:19 deploy today; every route 404'd
because neither Spring context would start.
MailOutboxService has @Transactional methods, so Spring has to proxy it, and
@EnableTransactionManagement in both WebDBContextConfigure classes runs with the
default proxyTargetClass=false. While the class implemented no interface Spring
proxied it with a CGLIB subclass, which is still a MailOutboxService. Adding an
interface switched it to a JDK proxy implementing only MailQueue, so all 39
sites that inject the concrete MailOutboxService failed:
BeanNotOfRequiredTypeException: Bean named 'mailOutboxService' is expected to
be of type MailOutboxService but was actually of type com.sun.proxy.$Proxy1519
The interface moves to a new MailQueueAdapter, which delegates to
MailOutboxService and carries no transactional annotations. MailQueueHolder and
EmailServiceImpl inject it by the MailQueue interface, so Utils.sendMail* and
EmailService still reach the outbox unchanged. MailOutboxService goes back to
implementing nothing, and its ~112 existing call sites are untouched.
Chose this over proxyTargetClass=true, which would have flipped proxying for
every interface-implementing service in the app -- too broad for a hot fix.
Verified with javap inside both built WARs: MailOutboxService declares no
interfaces, MailQueueAdapter implements MailQueue.
Note for cron: it shares the dao jar, so a rebuild picks this up. Do not restart
cron on trunk without rebuilding it first. |
|